CVE-2025-54096: Patch RRAS Out-of-Bounds Read in Windows VPN Gateways

Microsoft has published an advisory for CVE-2025-54096, a vulnerability in the Windows Routing and Remote Access Service (RRAS) that allows an out-of-bounds read and can be abused by a remote attacker to disclose sensitive information over a network — a high-priority fix for any server running RRAS or providing VPN/remote-access services.

Background / Overview​

RRAS (Routing and Remote Access Service) is a long-standing Windows Server role used to provide VPN termination, site-to-site routing, NAT, and legacy dial-up services. Because RRAS often runs at the network edge and under elevated privileges, vulnerabilities in its packet- and protocol-handling code can expose high-value information (session tokens, routing state, configuration, or even fragments of memory that include secrets). CVE-2025-54096 is reported as an out-of-bounds read (information-disclosure) issue in the RRAS packet-processing code that can be triggered by crafted network traffic.
Security advisories and community analysis for the RRAS vulnerability cluster in 2025 describe a recurring pattern: errors in buffer handling and use of uninitialized resources (CWE-908) lead to data leakage when RRAS processes crafted inputs. Those same advisories show Microsoft issuing timely security updates for affected Server SKUs and urging administrators to prioritize patching internet-facing RRAS endpoints.

---

What the vulnerability actually is​

Technical summary​

• Vulnerability type: Out‑of‑bounds read / use of uninitialized resource (information disclosure).
• Component: Windows Routing and Remote Access Service (RRAS).
• Impact: Remote disclosure of memory or internal state over the network; the attacker may obtain tokens, session metadata, routing information, or other residual memory contents that RRAS should not expose.

An out-of-bounds read tends to occur when code reads memory beyond the bounds of an allocated buffer or returns an uninitialized buffer to a caller. In network services like RRAS, that translated into an attacker being able to craft packets that cause the service to send back data it never intended to disclose. Because the leaked data can include authentication or routing artifacts, even small leaks can have outsized operational consequences.

Exploit vector and attacker requirements​

Microsoft’s advisory description for this CVE notes an authorized attacker can trigger the disclosure over the network. In practice, that wording can mean different things depending on deployment — it might imply an attacker needs to reach a negotiation stage of a VPN protocol or have some level of legitimate access, or it could simply reflect that RRAS accepts unauthenticated protocol negotiation traffic in some configurations. Treat any RRAS endpoint reachable from untrusted networks as high priority for patching and mitigation.
Common RRAS-handled protocols implicated across RRAS advisories include:

• PPTP (TCP 1723 + GRE 47)
• L2TP (UDP 1701; IKE UDP 500/4500 for IPsec)
• SSTP (TCP 443)
• IKE/IPsec control flows (UDP 500/4500)

Any RRAS interface exposed on these ports should be assumed potentially vulnerable until patched.

---

Affected products and scope​

RRAS is an optional Windows Server role. The practical exposure depends on whether the server has RRAS installed and active — many servers will not be affected by default, but enterprise VPN gateways, branch concentrators, and some cloud-based Windows images often run RRAS. Community summaries for 2025 RRAS advisories list affected Windows Server releases broadly as Windows Server 2016, 2019, 2022 and later builds when the RRAS role is present. Administrators must map the CVE to the exact KB(es) and update package for their specific SKU and build before applying updates.
Important operational note: some third‑party vulnerability feeds and aggregators have shown inconsistent CVE identifiers or KB mappings for related RRAS issues in 2025. The Microsoft Security Response Center (MSRC) update guide entry for CVE-2025-54096 is the authoritative source for which KB or monthly update contains the fix for each Windows SKU. Administrators should always reconcile CVE → MSRC entry → KB number for their exact builds. If alternate CVE IDs appear in reports, treat those as potential typographical or referencing errors until confirmed by MSRC.

---

Why this matters: operational risk and attack scenarios​

Even when a vulnerability is classified as information disclosure rather than remote code execution, its operational severity can be high for RRAS because:

• RRAS runs in privileged context (often SYSTEM) and processes network-level authentication material.
• Leaked memory may include tokens, session keys, or credential fragments that facilitate credential theft or offline cracking.
• Information disclosure is stealthy — it may not crash services or trigger obvious logs, enabling reconnaissance with low noise.
• Once attackers obtain configuration or routing information, targeted follow‑on attacks (pivoting, targeted RCE attempts, or lateral movement) become much easier.

Realistic attacker workflows include:

• Discovery: scanning for RRAS endpoints on standard ports (PPTP/L2TP/SSTP) and fingerprinting server responses.
• Probing: sending malformed/crafted negotiation packets to provoke out-of-bounds reads and collect leaked memory fragments.
• Triangulation: using leaked session metadata, routing tables or token fragments to craft further attacks (credential replay, targeted phishing, or escalation to RCE on susceptible components).

Past RRAS-related vulnerabilities in 2024–2025 attracted rapid community attention because network-facing services are high-value targets; defenders should therefore assume a realistic risk of weaponization and scanning activity after disclosure.

---

Immediate, prioritized response checklist​

Take these steps immediately — prioritize internet-facing RRAS endpoints and DMZ servers.

• Inventory: confirm where RRAS is installed and running.
• On a server (run elevated PowerShell):
• Get-Service -Name RemoteAccess
• Get-WindowsFeature | Where-Object { $.Name -match "RemoteAccess" -or $.Name -match "Routing" }
• If RRAS is not installed, the host is not affected. If it is, treat the host as in-scope until patched.
• Patch: identify and apply Microsoft’s security update for CVE-2025-54096.
• Use MSRC to map the CVE to the exact KB(s) for your Windows Server SKU and patch channel (Windows Update, WSUS, SCCM, Update Catalog).
• Apply the update to internet-facing RRAS hosts first, then to internal systems after testing.
• Verify installation (Get-HotFix or check Windows Update history) and confirm RRAS restarts cleanly.
• If immediate patching is not possible — contain and reduce exposure.
• Block or restrict RRAS/VPN ports at the perimeter:
• TCP 1723 (PPTP), GRE 47 (PPTP GRE)
• UDP 500 / 4500 (IKE/IPsec)
• UDP 1701 (L2TP)
• TCP 443 (SSTP)
• Apply IP allowlists to only permit client or partner IP ranges where feasible.
• Where RRAS is unnecessary, stop and disable the service:
• Stop-Service -Name RemoteAccess -Force
• Set-Service -Name RemoteAccess -StartupType Disabled
• If RRAS is not required, remove/uninstall the role:
• Uninstall-WindowsFeature -Name RemoteAccess -Restart (use caution; coordinate with operations).
• Hardening and access controls (short to mid-term).
• Enforce certificate-based authentication and MFA for VPN sign-ins.
• Use strong segmentation so RRAS management/administration is reachable only from hardened management networks.
• Apply Network Access Control (NAC) or Zero Trust principles to minimize the value of any leaked tokens/metadata.

---

Detection and monitoring: what to look for​

Effective detection helps find probes and early exploitation attempts. Prioritize these telemetry sources:

• Network sensors / IDS / IPS:
• Watch for anomalous or repeated connections to RRAS ports from unusual sources.
• Alert on malformed or unusual negotiation packet patterns and repeated probe-like traffic to VPN ports.
• Host and service logs:
• Review RRAS logs for unexpected negotiation attempts, frequent failed handshakes, or unusual session logs.
• Monitor Windows Event logs for RRAS crashes or abnormal service restarts (which may indicate probing or attempted exploitation).
• Endpoint and EDR telemetry:
• Look for suspicious processes, new accounts, or persistence mechanisms on RRAS hosts.
• Capture memory snapshots if you suspect active exploitation to enable forensic analysis; however, do so in a controlled manner to avoid impairing recovery operations.
• Hunt for downstream signs:
• After any suspected leak, hunt for credential misuse, anomalous authentication attempts against domain controllers, and lateral movement indicators. Use prioritized hunting queries that look for authentication anomalies from RRAS host IP addresses.

Detection guidance should be tuned to your environment’s normal RRAS usage patterns to reduce false positives but stay sensitive to scanning and malformed‑packet signatures.

---

Why some third‑party feeds disagree on details (and what to do)​

The RRAS CVE landscape in 2025 saw multiple related vulnerabilities across the same component, and early community write-ups sometimes referenced different CVE IDs, KB numbers, or impact descriptions (some RRAS bugs were information disclosure, others were heap-overflows leading to RCE). That produced occasional divergence between vendor MSRC entries, NVD, and vulnerability aggregator feeds.

• Practical implication: Do not rely solely on third-party aggregated CVE lists for the exact KB that fixes your build; always confirm the CVE → KB mapping in the Microsoft Security Update Guide (MSRC). Where third-party feeds diverge, treat their KB mappings as provisional until MSRC confirms them.
• Caveat: Some public summaries attributed RCE or heap-overflow impact to RRAS CVEs in the same timeframe; CVE-2025-54096 as reported in MSRC is an information‑disclosure/out‑of‑bounds‑read issue. Other nearby RRAS CVEs reported in 2025 included heap overflows and RCE potential. Distinguishing each CVE’s true impact requires consulting the vendor advisory for that specific CVE.

Flag any claim of exact CVSS scores, KB numbers, or exploit PoC availability as verifiable only after checking MSRC and the Microsoft Update Catalog for your SKU. If a third-party report does not match MSRC, assume the third-party report needs corroboration.

---

Hardening and longer-term mitigation strategies​

Beyond immediate patching, organizations should treat RRAS and any in-house VPN concentrator as a long-term control point that requires ongoing risk management:

• Inventory and minimize attack surface:
• Only deploy RRAS where necessary. Replace legacy RRAS deployments with modern, actively maintained VPN solutions where possible.
• Maintain a strict golden‑image baseline that does not include RRAS unless explicitly required.
• Network segmentation:
• Isolate VPN termination points from domain controllers and management systems.
• Use application-layer gateways or VPN‑specific appliances with additional deep‑packet inspection for externally exposed VPN endpoints.
• Defense-in-depth:
• Employ MFA, certificate-based authentication, and conditional access for remote access sessions.
• Use endpoint protection and memory‑protection tooling to limit what leaked memory could reveal or how leaked tokens can be abused.
• Patch management discipline:
• Map CVEs to installed SKUs and maintain a prioritized patch calendar that treats internet-facing remote access roles as critical.
• Use test‑first staging and phased rollouts for production updates but apply compensating controls for unpatched systems until the patch window closes.

---

Risk analysis and trade-offs​

Patching RRAS early reduces the window of exposure, but it can also introduce service-impact risk if updates change behavior or require configuration changes. Balance is needed:

• High risk (internet‑facing RRAS): The default posture is to patch immediately after a tested deployment in a staging environment or, if patching is impossible within your change window, block RRAS ports at the perimeter and whitelist management access. The potential impact of leaked credentials or tokens from a VPN gateway justifies accelerated remediation.
• Medium risk (internal RRAS): For RRAS instances only reachable from internal networks, prioritize patching but consider scheduled maintenance windows. Still apply monitoring and segmentation to limit lateral risk from compromised internal hosts.
• Low risk (no RRAS installed): If inventory shows RemoteAccess/RRAS is not present, no direct patch is required — but confirm images and templates across clouds and VMs to ensure it's not present on shadow instances.

---

What we still cannot verify (and why we flag it)​

• Exact KB article numbers for the patch that fixes CVE-2025-54096 for every Windows Server SKU may differ across third-party reports; administrators must confirm the precise KB mapping in MSRC for their build before applying updates. Any third-party KB mapping that doesn’t match MSRC should be treated as unverified.
• Public reports in 2025 sometimes confusingly referenced multiple RRAS CVE IDs with overlapping descriptions; while the broader technical pattern (uninitialized resource / out‑of‑bounds reads in RRAS) is corroborated, assigning other CVE numbers or claiming RCE for this specific CVE without vendor confirmation would be speculative. Validate each CVE individually against the MSRC entry.
• As of the advisory publication, there were no widely shared, reliable exploit proofs of concept for this exact CVE in the public domain. That can change quickly; assume exploitation tools could appear and maintain defensive urgency.

---

Practical remediation playbook (copy/paste)​

• Inventory hosts:
• Get-Service -Name RemoteAccess
• Get-WindowsFeature | Where-Object { $.Name -match "RemoteAccess" -or $.Name -match "Routing" }
• Map CVE to KB:
• Use the Microsoft Security Update Guide (MSRC) entry for CVE-2025-54096 to locate the KB(s) for your Server SKU. Confirm in Microsoft Update Catalog if necessary.
• Patch internet-facing instances first:
• Use WSUS/SCCM/Intune or manual Update Catalog download for critical hosts. Verify patch status with Get-HotFix or Windows Update history.
• Apply containment if delay is unavoidable:
• Block RRAS ports at the perimeter and whitelist known client IPs.
• Stop and disable the RemoteAccess service if not needed.
• Post‑patch verification and monitoring:
• Confirm RRAS service starts correctly and run targeted functional tests for VPN connectivity.
• Increase IDS/IPS sensitivity on RRAS ports for 7–14 days post-patch.

---

Conclusion​

CVE-2025-54096 is a serious information‑disclosure vulnerability in Windows RRAS that can leak internal memory across the network when an attacker can interact with RRAS protocol handlers. The combination of RRAS’s privileged context and its role at the network edge means the practical risk is high for exposed VPN gateways and DMZ servers. Administrators must immediately inventory RRAS instances, map the CVE to the correct Microsoft KB for their OS builds, and prioritize patching. If patching is delayed by operational constraints, implement strict perimeter filtering, disable unnecessary RRAS roles, and enable targeted detection and logging to reduce exploitation risk. Always verify CVE‑to‑KB mappings against the Microsoft Security Response Center entry and treat conflicting third‑party reports as requiring vendor confirmation.
Takeaway: treat RRAS hosts as critical assets for security operations — patch promptly, harden remote‑access controls, and assume that information‑disclosure bugs are stepping stones to more powerful attacks unless mitigated quickly.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center