Windows Spaceport.sys CVE-2026-70569

Exploitation requires an authenticated local account with at minimum standard user (non-administrator) privileges, consistent with the CVSS PR:L metric. The attacker must be able to execute arbitrary code locally - via interactive logon, Remote Desktop, or a pre-existing code execution foothold. The Spaceport.sys driver must be loaded, which occurs by default on all affected Windows installations that have the Storage Spaces feature active (default state). No special non-default configuration is required beyond a standard Windows install. Exploitation is strictly local-access only (AV:L): remote-only attackers without an existing foothold on the target system cannot reach the vulnerable driver.

The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, score 7.8) accurately characterizes the exploitation profile: a low-privileged local account, no user interaction, low complexity, and full kernel-level impact post-exploitation. The AV:L attack vector is the primary risk limiter - the attacker must already hold a foothold on the target system, ruling out remote unauthenticated exploitation. No EPSS data was provided in the input; however, Windows kernel driver LPEs are consistently targeted by ransomware operators and APT groups for privilege escalation during post-compromise lateral movement, making this a genuine priority for enterprise environments. KEV status is not confirmed and no public POC has been identified at time of analysis, so urgency is lower than for actively exploited issues. Highest risk environments: shared workstations, Remote Desktop Services hosts, and cloud VM multi-tenant scenarios where untrusted local users may be present.

An attacker with a standard (non-administrator) local user account on a Windows 11 workstation or Windows Server Remote Desktop host executes crafted code that triggers the out-of-bounds read in Spaceport.sys, leaking a kernel pointer to defeat ASLR. The attacker chains this information leak with a secondary kernel write primitive to overwrite a security token or callback pointer and elevate to SYSTEM. No public proof-of-concept has been identified at time of analysis, but this two-stage info-leak-to-write kernel LPE pattern is a well-established exploitation class in Windows kernel research.