CVE-2025-60713: Patch Windows RRAS Local Privilege Escalation Now

Microsoft’s public advisories list CVE-2025-60713 as a genuine, high‑priority vulnerability in the Windows Routing and Remote Access Service (RRAS) that can allow a local, low‑privileged user to elevate to higher privileges through an untrusted pointer dereference in RRAS — administrators must treat RRAS‑enabled hosts as in‑scope, patch quickly, and apply network and host mitigations until updates are confirmed.

Background​

Routing and Remote Access Service (RRAS) is the Windows Server role that implements VPN termination (PPTP, L2TP/IPsec, SSTP), NAT and legacy routing services. RRAS commonly runs with elevated privileges and processes complex, attacker‑controlled network and interprocess inputs, so memory‑handling defects in its code paths are particularly consequential. The RRAS family of bugs reported across 2024–2025 includes out‑of‑bounds reads, use‑of‑uninitialized resources, and heap‑based overflows — all of which have appeared repeatedly in vendor advisories and community writeups, and which make RRAS a high‑value target for attackers.
CVE-2025-60713 is explicitly reported as an untrusted pointer dereference in RRAS that permits local elevation of privilege. Public aggregators give the issue a high base severity (CVSS ~7.8) and list the vulnerability as fixed via Microsoft Update for supported Windows Server lines. Independent trackers and forum writeups echo the same operational advice: identify RRAS instances, apply the vendor KB that maps to the CVE for each OS build, and urgently remediate internet‑facing or otherwise reachable RRAS endpoints.

---

What CVE-2025-60713 actually is​

Technical summary (plain language)​

• Root cause: untrusted pointer dereference in the RRAS code path — a memory‑safety bug where RRAS follows or uses a pointer supplied by an untrusted context without sufficient validation. In practice that can corrupt memory, cause unexpected code paths to execute, or allow an attacker to manipulate process state in ways that escalate privileges.
• Vulnerable component: Windows Routing and Remote Access Service (RemoteAccess role/service) when installed and running. RRAS is not installed by default on most SKUs, but remains common in on‑prem VPN and branch gateway deployments.
• Attack vector: Local — exploitation requires code executing on the host (a local account). No user interaction is required in many scenarios. The attacker must have some foothold (e.g., unprivileged shell or compromised user process) or run code locally and then call the vulnerable RRAS interface.
• Impact: Elevation of privilege (EoP) — realistic worst case is SYSTEM‑level behavior, enabling persistence, credential theft, or full host compromise.

Why pointer dereferences matter here​

Untrusted pointer dereference is different from a pure information disclosure or a simple out‑of‑bounds read: it often allows manipulation of flow or state because the component trusts memory references it should not. In privileged services such as RRAS, that trust can be converted into SYSTEM capabilities through token manipulation, vtable hijacking, or targeted corruption of in‑process structures. Historically, COM components and long‑running privileged services have been exploited this way once local access is available. Forum and vendor analyses of RRAS‑class bugs throughout 2025 repeatedly highlight this exploitation pattern and emphasize how quickly adversaries weaponize local EoP primitives once they exist.

---

Scope: who should care and why right now​

• Any Windows host with the RRAS/RemoteAccess role installed and the RemoteAccess service running is potentially affected. RRAS is optional but widely used for VPN termination and branch gateway roles, which are often reachable by attackers.
• Because exploitation requires local access, the highest‑risk scenarios are:
• Hosts where untrusted code can already run (developer machines, terminal servers, systems allowing user installs).
• Hosts that have been partially compromised (initial foothold through phishing/malware), where a local EoP converts limited access into full system compromise.
• Systems where RRAS is combined with other services that accept remote input (e.g., RDP sessions to an RRAS host), increasing the attack surface.
• Internet‑facing RRAS servers remain operationally significant because a remote compromise that yields local code execution can be chained to this EoP. Even where RRAS itself is not remote‑exploitable, attackers treat any EoP as a force multiplier after initial compromise.

---

Verification, confidence, and conflicting records​

Microsoft’s Security Update Guide (MSRC) is the canonical authority to confirm affected builds, KB numbers, and the exact remediation packages. Community aggregators (Feedly, CVE trackers, vulnerability blogs) and forum investigations generally corroborate vendor advisories, but third‑party CVE→KB mappings have been inconsistent for RRAS entries in 2025, so always use MSRC as the final source when mapping the CVE to a patch for a given Windows build. If an MSRC page is difficult to render programmatically, open it in a full browser session and note the KB. Independent aggregators show strong convergence on the core facts for CVE-2025-60713 — the vulnerability exists, Microsoft has published a fix, and the CVSS is high — which together produce high confidence that the issue is real and should be remediated. At the same time, Microsoft’s public advisory typically omits exploit mechanics; where exact internal details or PoC code are absent, treat any publicly circulated exploitation claims with caution until corroborated by multiple independent, high‑quality technical analyses.

---

Practical risk analysis and attacker scenarios​

Immediate attacker workflows (realistic)​

• Initial foothold: attacker obtains an unprivileged shell via phishing, malicious installer, or lateral pivot.
• Local probe: attacker calls the RRAS interface or invokes an action that leads RRAS to process attacker‑controlled pointers or data.
• EoP exploitation: crafted inputs cause RRAS to follow untrusted pointers or corrupt process state, enabling token replacement, code execution in RRAS context, or other privilege elevation techniques.
• Post‑exploit actions: deploy persistence, dump credential material (LSASS), move laterally, or install ransomware.

Because local EoPs are high value, defenders should assume exploitation is both attractive and actionable to skilled attackers and that exploit code or weaponized toolsets may appear in the wild after disclosure even if no PoC is public at disclosure time. Historical RRAS advisories and the cluster of memory‑safety RRAS CVEs in 2025 demonstrate the speed at which opportunistic actors scan and attempt to exploit exposed hosts.

Exploit complexity and prerequisites​

• Prerequisite: local code execution or ability to call RRAS interfaces as an authenticated local account. This is a low bar in many environments where users can run code or where endpoint compromise is already possible.
• Complexity: moderate — pointer dereference exploits often require a good understanding of the target process’s memory layout and may require some heap/stack manipulation. However, once a reliable primitive exists, attackers rapidly generalize and automate exploitation.

---

Detection, hunting, and telemetry​

Information from vendor guidance and community playbooks converges on the following high‑value telemetry and detection points for RRAS EoP scenarios:

• Host logs:
• Monitor Windows Event Logs for RRAS/RemoteAccess service crashes, abnormal restarts, or unusual error codes. Forward Application and Services Logs → Microsoft → Windows → RemoteAccess and RasMan to your SIEM.
• EDR/endpoint:
• Hunt for new service token changes, unexpected child processes spawned by privileged services, or unusual lsass.exe accesses following alerts on RRAS hosts.
• Network:
• Even though exploitation is local, network signals often show reconnaissance or follow‑on lateral movement from exploited hosts. Watch for anomalous traffic to RRAS‑related ports or spikes in outbound connections from RRAS hosts.
• Packet capture:
• If you suspect probing or exploitation, capture network traffic to RRAS interfaces and inspect for unusual payloads or negotiation anomalies. Preservation of packet captures and memory snapshots aids forensic analysis.

Detection guidance should be tuned to normal RRAS usage in each environment to reduce false positives but remain sensitive to scanning and malformed‑input patterns.

---

Immediate mitigation and remediation playbook (24–72 hours)​

Apply the following prioritized actions — these are practical, sequential steps for operators who must triage the risk quickly.

• Inventory (minutes):
• Confirm where RRAS is installed and whether the RemoteAccess service is running:
• Get-Service -Name RemoteAccess
• Get-WindowsFeature | Where-Object { $.Name -match "RemoteAccess" -or $.Name -match "Routing" }
• Patch (hours):
• Map CVE-2025-60713 to the exact KB for your Windows Server build using Microsoft’s Security Update Guide and apply the security update. Prioritize internet‑facing RRAS hosts, management hosts with multiple user roles, and systems exposed to contractor or shared accounts.
• If patching is delayed (temporary mitigations):
• Stop the RemoteAccess service where feasible:
• Stop-Service -Name RemoteAccess -Force
• Set-Service -Name RemoteAccess -StartupType Disabled
• Block or restrict RRAS/VPN ports at the perimeter and host firewall:
• TCP 1723 (PPTP), GRE (47), UDP 1701 (L2TP), UDP 500/4500 (IKE/IPsec), TCP 443 (SSTP). Apply IP allowlists for known client IP ranges when possible.
• Harden and monitor (days):
• Enforce least privilege for local accounts, restrict local execution where possible, enable application allow‑listing (AppLocker or WDAC), and increase logging/EDR coverage on RRAS hosts.
• Forensic preparedness:
• If compromise is suspected, capture volatile memory and packet captures in a controlled way to preserve evidence for root cause analysis. Coordinate with your IR team and EDR vendor for safe acquisition.

---

Longer‑term recommendations and hardening​

• Reassess the use of RRAS: where possible, use vendor‑managed VPN gateways, cloud native VPN services, or modern, hardened appliances that reduce your exposure to Windows role bugs. RRAS remains useful but is a larger attack surface for privileged memory‑safety issues.
• Replace legacy protocols: phase out PPTP and other legacy protocols; prefer modern, well‑maintained VPN stacks with strong crypto and certificate‑based authentication.
• Patch governance: maintain a CVE→KB→build mapping in your CMDB and verify updates via WSUS/Intune/SCCM with staged rollouts and quick rollback plans for problematic updates. Community reporting in 2025 shows inconsistent CVE→KB mapping across feeds, so the MSRC entry is authoritative.
• Incident readiness: include RRAS compromise scenarios in tabletop exercises, and practice quick‑isolation playbooks to remove internet exposure from compromised or high‑risk hosts.

---

Strengths and weaknesses of the public record (confidence analysis)​

Strengths:

• Vendor acknowledgement and shipped fixes are the strongest signal that a vulnerability is real; MSRC postings plus independent aggregators converging on a high severity rating provides high operational confidence that CVE-2025-60713 is legitimate and important to remediate.
• Community playbooks and forum writeups provide practical detection and mitigation steps that teams can adopt immediately.

Limitations and cautions:

• Microsoft advisories intentionally omit detailed exploit mechanics; public PoC code or deep technical writeups may be absent at disclosure. Any third‑party PoC should be treated with caution until validated by multiple reputable researchers.
• Several public feeds and aggregators historically showed inconsistent CVE→KB mappings for RRAS CVEs in 2025. That inconsistency can cause operational errors (patching the wrong build). Always verify the KB for your exact build via MSRC.
• The NVD and other centralized trackers can lag for new CVEs; absence of a NVD entry does not imply the issue is unpatched or unimportant — rely on MSRC and vendor KBs for actionability.

---

Quick checklist (actionable items)​

• Inventory: find all hosts with RRAS/RemoteAccess installed and running.
• Patch: map CVE-2025-60713 to your OS build’s KB in MSRC and apply updates.
• Contain (if you can’t patch immediately):
• Stop RRAS service where feasible.
• Block RRAS/VPN ports at the perimeter and restrict management access.
• Monitor: forward RRAS logs, tune IDS/EDR hunts for anomalous activity.
• Forensics: capture memory and packet traces in a controlled manner if exploitation is suspected.

---

Conclusion​

CVE-2025-60713 is a confirmed, high‑risk local elevation‑of‑privilege in Windows RRAS that has been addressed by Microsoft updates and is widely recognized by independent trackers and community analyses. The real operational danger is not only the EoP itself but the speed with which attackers can use local EoP primitives to move from limited access to full host compromise. For any organization that allows local code execution or runs RRAS on gateway hosts, the correct immediate response is inventory, apply the vendor‑supplied update for your exact Windows builds, and use network/host mitigations to reduce exposure while you validate patch deployment. Treat Microsoft’s Security Update Guide as authoritative for KB mappings, and treat any CVE→KB mismatch in third‑party feeds as a flag to verify before deploying updates. If MSRC pages are difficult to render in automated tooling, open them in a full browser session and record the KB numbers you will deploy — that final mapping is what ensures remediation was applied to the correct builds.

---

Key operational phrase for triage: patch immediately, inventory RRAS, and isolate RRAS hosts if you cannot patch.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center