A new Microsoft Security Response Center advisory published on November 11, 2025, documents CVE‑2025‑59510 — a
local denial‑of‑service (DoS) vulnerability in Windows Routing and Remote Access Service (RRAS) that stems from improper link resolution (symlink or "link following") before file access. The issue allows an
authorized local attacker to trigger service disruption of RRAS on affected hosts; Microsoft has released a security update to address the problem and the reported CVSS v3.1 base score is
5.5 (Medium), with the vector indicating a locally exploitable availability impact.
Background
Routing and Remote Access Service (RRAS) is a longstanding Windows Server role commonly used for VPN termination (PPTP, L2TP/IPsec, SSTP), NAT, and routing. RRAS runs with elevated privileges and handles complex network and filesystem interactions, so bugs in its code paths can have outsized operational impact. Throughout 2025 RRAS has been the subject of a cluster of memory‑safety and protocol‑parsing vulnerabilities; those prior incidents underscore why even a
local DoS in the RRAS service is operationally meaningful for organizations that rely on it for perimeter VPN or branch‑gateway functions. CVE‑2025‑59510 differs from many earlier RRAS issues in 2025 because it is not a network‑facing memory disclosure or heap‑corruption bug: the report describes
improper link resolution before file access (CWE‑59) that can be abused by an
authorized local user to deny service. That distinction changes both the threat model and the immediate mitigations required.
What Microsoft says (concise technical summary)
- Vulnerability: Improper link resolution before file access (link following / symlink handling) in RRAS.
- Impact: Local denial of service — attacker can cause the RRAS service to stop or fail in a way that disrupts routing or VPN termination.
- Attack Vector: Local (requires an attacker able to perform file system operations on the host with limited privileges described as “authorized attacker”). Remote exploitation is not indicated in the advisory.
- Privileges Required: Low / Authorized local privilege (exact minimum rights depend on environment).
- CVSS v3.1 (vendor-provided): 5.5 / AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H (Medium).
These vendor statements are reflected in multiple public CVE aggregators and tracking feeds; at time of publication there were no public proof‑of‑concept exploits reported and no confirmed active exploitation.
Technical analysis — how the bug works
Root cause: link‑following before file access
The flaw arises when RRAS performs file system link resolution (following symbolic links or reparse points) in a manner that permits an attacker‑controlled link to cause an unexpected file access or failure path. If RRAS depends on a file path that is resolved insecurely (for example, following a symlink that points to an unexpected or protected resource), a local actor who can create or manipulate links may cause the service to encounter an error condition or crash, producing a denial of service. This class of defect is cataloged under CWE‑59 (improper link resolution) and is distinct from memory corruption or remote protocol parsing bugs.
Attack model and prerequisites
- Attacker must have local access to the affected host — for example, an authenticated user account on the server or an attacker with limited local file system privileges. The advisory describes the actor as “authorized,” indicating some legitimate access is required.
- The attacker must be able to create or manipulate a symbolic link / reparse point or place files where RRAS will perform link resolution. The exact file paths and link targets that trigger the condition are described in vendor details; administrators should consult the MSRC advisory for the KB mapping to their build.
- Exploitation leads to availability impact (service crash, hang, or error state) rather than confidentiality or integrity loss by itself. However, availability of VPN and routing services is often critical; the downstream operational impact can be severe.
Why this matters operationally
RRAS typically runs in a privileged context on servers that act as VPN gateways, site termination points, or branch routers. A local DoS that knocks RRAS offline can cut remote user access, disrupt VPN‑based authentication and single sign‑on flows, and impede administrative access to edge infrastructure. For organizations with high availability requirements or strict service‑level agreements, the availability impact can create immediate business risk even though the vulnerability is not remotely exploitable. Historical coverage of RRAS vulnerabilities in 2025 shows that RRAS endpoints are high‑value targets and often lack centralized inventory visibility, increasing the chance that vulnerable instances will persist unpatched.
Evidence and independent corroboration
Multiple independent CVE trackers and security feeds reflect the same technical picture: local symlink / link‑following issue in RRAS leading to local denial of service and a vendor‑assigned CVSS of 5.5. Aggregators such as CVEFeed, CVE Details and security tracking services reported the CVE entry and mirrored the Microsoft advisory metadata; the Microsoft Security Update Guide hosts the authoritative advisory page (which requires a browser to render). There were no widely‑reported public exploits or proof‑of‑concepts at the time of advisory publication. Caveat: Some third‑party feeds and public CVE mirrors may lag or show slightly different product mappings; always reconcile the CVE → KB → update mapping directly in Microsoft’s security update guide and your organization’s patch management console before deploying updates. Prior RRAS advisories in 2025 exhibited inconsistent CVE→KB mirroring across vendors and feeds, which can complicate triage.
Immediate operational guidance (0–72 hours)
Follow this prioritized checklist to reduce risk and restore service availability where necessary.
1. Patch now (highest priority)
- Identify the Microsoft security update that remediates CVE‑2025‑59510 for each Windows Server build in your estate using Microsoft’s Security Update Guide. Confirm the KB number before deployment.
- Schedule and apply the vendor update through your standard channels (WSUS, SCCM, Intune, Microsoft Update Catalog). Test on a staging host before broad rollout when feasible.
2. If immediate patching is impossible — apply temporary containment
- Restrict local administrative and file‑write access on RRAS hosts to a minimal set of trusted accounts. Remove or limit generic service accounts that can log on locally.
- Harden the host filesystem: set strict ACLs on directories RRAS uses, and audit attempts to create reparse points or symlinks in those locations.
- If RRAS is not required on a host, stop and disable the RemoteAccess service until a patch is applied. Use: Get‑Service -Name RemoteAccess; Stop‑Service -Name RemoteAccess -Force; Set‑Service -Name RemoteAccess -StartupType Disabled.
3. Increase monitoring and collect evidence
- Forward RRAS‑related logs to your SIEM: Applications and Services Logs → Microsoft → Windows → RemoteAccess and RasMan. Alert on service crashes, restarts, and repeated file access errors.
- Monitor for unusual local file system activity where symlinks, junctions, or reparse points are normally not expected. Retain filesystem audit logs for investigation.
- If you suspect an exploit or repeated crashes, capture crash dumps and preserve volatile memory and packet captures for forensic review prior to remediation.
4. Communicate and coordinate
- Inform service owners and network operations teams of the potential for RRAS outages during emergency remediation windows.
- Prepare rollback plans and a validated recovery procedure to bring RRAS back online if a patched system behaves unexpectedly.
Detection and hunting playbook
Use the following short, practical queries and checks to detect attempts and verify remediation:
- Inventory RRAS installations:
- Get‑Service -Name RemoteAccess
- Get‑WindowsFeature | Where‑Object { $.Name -match "RemoteAccess" -or $.Name -match "Routing" }
These commands quickly reveal which servers have the RRAS role present.
- SIEM rules and log monitoring:
- Alert on RemoteAccess / RasMan event IDs indicating service errors or repeated negotiation failures. (Event ID specifics vary by build; consult vendor logging documentation.
- Alert on Windows Security and Sysmon events that show creation of NTFS reparse points, creation/modification of symlinks in RRAS configuration paths, or unexpected file operations by the RRAS process account.
- Host forensic captures:
- On suspected hosts, preserve process memory or create a full system memory image.
- Collect RRAS crash dumps, system event logs, and any recent file system audit trails.
- Document file paths and link targets present in the RRAS config directories to check for malicious symlink manipulation.
Patch management and validation
- Verify KB mapping: Do not rely solely on third‑party mirrors. Use Microsoft’s Security Update Guide entry for CVE‑2025‑59510 to obtain the exact KB for each OS build. Confirm in your patching tool that the correct update package is targeted to each host.
- Post‑patch validation steps:
- Confirm the RemoteAccess service starts cleanly and no repeated RSAS error events occur.
- Reboot hosts where required and validate VPN connectivity from representative client configurations.
- Re‑enable previously‑restricted local accounts only after confirming the host is patched and logging/auditing is active.
Strategic and long‑term recommendations
- Minimize RRAS usage where possible. Modern managed VPN gateways (cloud or appliance‑based) reduce the attack surface and remove the need for fragile host‑level symlink management. Continued operation of RRAS should be justified by policy and subject to continuous monitoring.
- Implement stricter local privilege separation on servers that host RRAS: reduce the number of accounts with local write permissions, enforce Device Guard / AppLocker policies, and enable controlled folder access where appropriate.
- Maintain an authoritative CMDB with role installation flags (e.g., whether RemoteAccess is installed) to avoid unmanaged RRAS instances lingering in the environment. Prior RRAS advisories exposed gaps between inventory and reality.
- Conduct periodic red‑team or tabletop exercises that include local symlink and filesystem manipulation scenarios to validate detection and response playbooks.
Risk assessment — strengths and caveats
Strengths
- Microsoft released an update on the same day the CVE was published, enabling defenders to remediate quickly when they prioritize patches. The vendor CVSS metadata (5.5) correctly frames this as a medium‑severity availability issue rather than an immediate remote code execution risk.
Caveats and residual risk
- Inventory gaps: RRAS is an optional role and is often under‑tracked; an unpatched but offline or lightly used RRAS instance could still be a single point of failure if relied upon for remote access. Public RRAS advisories in 2025 repeatedly called out inconsistent CVE→KB mirroring across external trackers, which can slow remediation if teams rely on third‑party summaries. Always reconcile with MSRC.
- Local threat vs. remote threat: Because this vulnerability requires local access, its likelihood of exploitation across internet‑facing hosts is lower than for network‑exploitable RRAS bugs; however, insider threats, compromised service accounts, or chained attacks that produce local access must be considered. If host access controls are weak, an attacker may be able to exploit this condition to amplify disruption.
What could not be independently verified (flagged claims)
- Public exploit availability: At the time of advisory publication and follow‑up checks, there was no confirmed public proof‑of‑concept or reports of in‑the‑wild exploitation for CVE‑2025‑59510. If you observe exploit code or indicators referencing this CVE in external feeds, treat that as a high‑urgency signal and isolate affected hosts immediately.
- Exact filesystem paths and symlink patterns exploited: Microsoft’s MSRC advisory is the authoritative reference for precise mitigation text and KB mapping. Some third‑party mirrors summarize the flaw at a high level but do not publish the full technical triggers; for operational patching and forensic follow‑up, verify the MSRC advisory and the KB article tied to your build. Where vendor content required a full browser to render, automated scrapers sometimes omit critical KB mapping details — confirm in a browser session.
Conclusion — prioritized action summary
- Confirm whether any host in your environment runs the RRAS / RemoteAccess role. Use the provided PowerShell checks and inventory tools.
- Map CVE‑2025‑59510 to the exact KB(s) for your Windows Server builds in Microsoft’s Security Update Guide and apply the vendor update as soon as possible.
- If immediate patching is not possible, restrict local write and symlink creation privileges on RRAS hosts, disable RRAS where unused, and harden filesystem ACLs.
- Monitor RRAS logs and system events for signs of service instability, symlink creation, or unexpected file access failures. Preserve crash dumps and audit trails for any incident investigations.
CVE‑2025‑59510 is a reminder that availability‑focused vulnerabilities can have outsized operational impact even when they require local access. For organizations that depend on RRAS for perimeter VPN and routing functions, rapid inventory, targeted patching, and tighter host‑level controls are the most reliable defenses.
Source: MSRC
Security Update Guide - Microsoft Security Response Center