Microsoft has released a security update for a high-severity local privilege escalation vulnerability in the Windows Routing and Remote Access Service (RRAS) that could allow an attacker with a foothold on a server to gain full SYSTEM-level control. Tracked as CVE-2025-60713, the flaw carries a CVSS score of 7.8 and affects all supported Windows Server versions where the RRAS role is installed.

The Vulnerability at a Glance

The bug stems from an untrusted pointer dereference inside the RRAS code. When the service processes certain requests, it can be tricked into following a pointer that hasn’t been properly validated—essentially trusting an attacker-controlled memory address. In practical terms, this memory-safety slip lets a skilled attacker manipulate process state, redirect execution flow, or corrupt critical data structures. Because RRAS runs with elevated privileges, the end result is often a direct path to SYSTEM access.

The vulnerable component, the RemoteAccess service, is not enabled by default. It appears on servers configured as VPN gateways (supporting PPTP, L2TP/IPsec, SSTP, or IKEv2), LAN routers, or NAT appliances. Once RRAS is installed and running, the attack surface expands, and any local user—even one with minimal rights—can potentially trigger the exploitable code path.

Exploitation requires the attacker to already have code execution on the target machine. That might come from a phishing attack, a malicious installer, an unpatched remote code execution bug, or simply a shared terminal server where users can run arbitrary programs. But with a local foothold, the RRAS flaw becomes a force multiplier: it turns limited access into complete compromise.

Who’s at Risk?

The vulnerability chiefly concerns IT administrators managing Windows servers that host the RRAS role. If you run a VPN server, a branch-office router, or any system that terminates remote connections via the Routing and Remote Access console, you are squarely in scope. The same applies to servers that have the RemoteAccess feature enabled even if they aren’t actively used for VPN—perhaps leftover from a previous configuration.

Home users and standard Windows 10 or 11 workstations are largely unaffected, because the Desktop Experience doesn’t include the full RRAS role. However, power users who installed RRAS on a Windows client for testing or niche routing scenarios should verify and patch.

Organisations with terminal servers, jump boxes, or development machines that allow multiple users to log in interactively face a higher risk. Here, an unprivileged domain user could escalate to SYSTEM, dump credentials, and move laterally across the network.

How Attackers Exploit This Flaw

Public technical specifics remain limited, as is common with Microsoft advisories. But the untrusted pointer dereference classification points to a classic memory corruption scenario. An attacker crafts a request that causes RRAS to read or write to a location they control. If they can place shellcode or a return-oriented programming (ROP) chain at that location, they can hijack the service’s execution and run arbitrary code as SYSTEM.

Attack sequences often follow this pattern:

  1. Initial compromise – Phishing, malware, or exploitation of another flaw yields a low-privilege shell.
  2. Local reconnaissance – The attacker confirms RRAS is installed and listens for locally accessible interfaces (e.g., named pipes, COM objects, or RPC endpoints).
  3. Trigger – A crafted call to the vulnerable function causes RRAS to dereference a malicious pointer.
  4. Escalation – The attacker redirects execution, replaces the process token, or injects code to obtain SYSTEM rights.
  5. Post-exploitation – Credential theft (LSASS dumping), persistence mechanisms, or lateral movement ensues.

RRAS has been a recurring target. Throughout 2024 and 2025, Microsoft addressed multiple memory-safety bugs in the same role—out-of-bounds reads, use-after-free, heap overflows—all exploitable for local privilege escalation. The pattern suggests that the codebase, which handles complex network and inter-process input, remains a rich hunting ground for researchers and attackers alike. CVE-2025-60713 is the latest in a series that underscores why every RRAS deployment must be kept patched and hardened.

The Patch and Immediate Workarounds

Microsoft resolved the issue through its standard monthly security release. The fix is distributed via Windows Update, WSUS, and the Microsoft Update Catalog. Because the CVE-to-KB mapping can vary per build, administrators should consult the Microsoft Security Update Guide directly for the exact update package that corresponds to their server’s OS version.

If you cannot apply the patch immediately, these temporary mitigations reduce risk:

  • Disable the RemoteAccess service on servers where RRAS is not mission-critical. Run Stop-Service -Name RemoteAccess -Force and set the startup type to Disabled.
  • Restrict network access to RRAS listening ports. Block TCP 1723 (PPTP), GRE (protocol 47), UDP 1701 (L2TP), UDP 500/4500 (IKE/IPsec), and TCP 443 (SSTP) at the host firewall or perimeter, except for known VPN client IP ranges.
  • Remove or uninstall the RRAS role if the server no longer serves as a router or VPN endpoint. Use Server Manager or the Uninstall-WindowsFeature RemoteAccess PowerShell cmdlet.

None of these workarounds fully eliminate the vulnerability, but they drastically shrink the attack surface while you schedule patching.

Defense in Depth: Detection and Hardening

Even with the patch, RRAS servers remain high-value targets. Consider these longer-term safeguards:

  • Log and monitor – Enable enhanced logging for the RemoteAccess and RasMan event channels (found under Applications and Services Logs → Microsoft → Windows). Forward unusual error codes, service crashes, or repeated restart attempts to your SIEM. Sudden spikes in failed VPN authentication attempts may indicate probing.
  • Endpoint detection and response (EDR) – Hunt for suspicious child processes spawned by svchost.exe -k RasMan or unexpected token privilege changes. Any access to LSASS memory from a remote-access service context should raise an alert.
  • Apply least privilege – Restrict who can log on locally to RRAS hosts. Use jump boxes with multi-factor authentication for administrative access. Where possible, enforce application control (WDAC or AppLocker) to prevent untrusted code execution.
  • Deprecate legacy VPN protocols – Phase out PPTP and MS-CHAPv2 in favor of modern, certificate-backed protocols like IKEv2 or SSTP with strong cipher suites. Reducing protocol complexity shrinks the attack surface.
  • Isolate RRAS servers – Place them in a dedicated management segment, away from domain controllers and critical line-of-business servers. If an attacker does compromise an RRAS box, lateral movement should be as difficult as possible.

If you suspect prior exploitation, preserve volatile evidence: capture a memory dump of the RemoteAccess service, save firewall and event logs, and take a packet trace of RRAS-related traffic before rebooting or patching. Engage your incident response team to look for signs of credential harvesting or backdoors.

What’s Next

This CVE is not an isolated blip. RRAS continues to receive CVE after CVE, indicating that its aging codebase struggles with modern memory-safety standards. Microsoft’s own advisory is matter-of-fact, but the external security community has flagged RRAS as a recurring weak point. Expect additional patches in the months ahead—particularly as more researchers apply fuzzing and static analysis tools to networking roles.

For now, the operational message is clear: identify every RRAS instance in your environment, apply Microsoft’s fix, and adopt the layered defences outlined here. The difference between an attempted escalation and a successful takeover often comes down to whether the latest security update was deferred or deployed.

Quick action list

  1. Inventory – Get-Service RemoteAccess and Get-WindowsFeature | Where-Object { $_.Name -match "RemoteAccess" } across all Windows servers.
  2. Patch – Visit the MSRC entry for CVE-2025-60713, download the correct KB for each build, and deploy via your standard update tooling.
  3. Contain – On high-risk servers, stop the RemoteAccess service or block its ports until the patch is confirmed.
  4. Monitor – Feed RRAS operational and security logs to your SIEM, and tune detection rules for anomalous behavior.