Windows RRAS EUVD-2026-73109

Exploitation requires a network-reachable RRAS instance (the Routing and Remote Access Service role must be installed and running - it is not enabled by default on Windows clients or servers), plus a valid low-privilege account (PR:L) to authenticate to the service. No user interaction is required beyond the attacker's own network access. Limiting factors: RRAS must be explicitly deployed as a server role; the attacker must hold a domain, local, or VPN-credential account; and the vulnerable host must be network-reachable on the RRAS port(s). Client-only Windows installs without the RRAS role enabled are not exposed.

The CVSS 3.1 score of 6.5 (Medium) reflects an authenticated network path with no scope change and no confidentiality or integrity impact. Real-world risk is moderate: while RRAS must be explicitly configured as a server role (reducing attack surface compared to always-on services), organizations relying on it for remote-access VPN face meaningful operational disruption if the service is crashed. No CISA KEV listing and no public POC code have been identified, reducing urgency relative to unauthenticated or RCE-class RRAS flaws. The PR:L requirement means the attacker must hold at least a domain or local account, which limits opportunistic exploitation but does not prevent insider threat or compromised-credential scenarios. EPSS data is not provided; the combination of no KEV, no POC, and a PR:L requirement suggests this is a low-to-moderate exploitation probability in the near term.

An authenticated attacker - such as a domain user or a remote-access client already connected via VPN - sends a specially crafted network packet to the RRAS listener. The malformed input causes a null pointer dereference inside the RRAS process, crashing the service and severing active remote-access sessions for all connected users. No public proof-of-concept is known at time of analysis, but the low complexity and network attack vector make the crash reproducible by trial-and-error.