Windows SSTP CVE-2026-73009

Exploitation requires the target to be running the Windows SSTP service - i.e., a host configured as an SSTP VPN endpoint via the Routing and Remote Access Service, with the SSTP listener reachable by the attacker over the network; this VPN role is not enabled by default, which is the primary factor limiting real-world exposure. When SSTP is exposed, the CVSS vector indicates no authentication (PR:N) and no user interaction (UI:N) are required. A secondary vector affects Windows clients that connect to a malicious or spoofed SSTP server. Practical exploitation is further limited by the reliability challenges inherent to weaponizing a heap use-after-free remotely.

The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N, C:H/I:H/A:H) presents a maximal, network-reachable, unauthenticated, no-interaction RCE - a top-priority profile on paper, and Microsoft assigning it directly (secure@microsoft.com) lends credibility to the impact rating. However, two signals temper real-world urgency: no EPSS score, KEV entry, or public POC is present in the provided data, so this is not confirmed as actively exploited, and reliably weaponizing a use-after-free over the network typically requires heap grooming and winning a race, which argues the effective attack complexity is higher than the AC:L rating suggests. Most importantly, SSTP is a VPN listener that must be enabled/exposed via RRAS; it is not active on default Windows installations, so the true attack surface is limited to hosts configured as SSTP VPN gateways (plus clients connecting to malicious/spoofed SSTP endpoints). Bottom line: patch promptly on any RRAS/SSTP VPN infrastructure, but for typical endpoints that do not run SSTP the immediate exposure is low despite the 9.8.

An attacker locates an internet-facing Windows RRAS server offering SSTP VPN and sends a crafted sequence of SSTP protocol messages that triggers the use-after-free and reuses the freed object, corrupting heap memory to hijack control flow and execute code in the privileged service context. Given AV:N/PR:N/UI:N, no credentials or user interaction are needed, though reliable exploitation of a UAF over the network is non-trivial and no public POC is currently known.