Windows Spaceport.sys CVE-2026-71348

Physical access to the target machine is the absolute prerequisite - this vulnerability cannot be triggered remotely or over a network. No authentication credentials or existing user account are required; an attacker needs only the ability to interact physically with the hardware or attached devices to trigger the Spaceport.sys heap overflow. The Storage Spaces driver is loaded on all supported Windows installations by default, so no non-default configuration is required beyond the attacker achieving physical proximity. Exploitation is limited by: (1) mandatory physical access to the target machine, (2) the need for kernel heap-shaping expertise to turn the overflow into reliable code execution, and (3) Secure Boot and kernel patch guard (KPP/PatchGuard) may complicate stable post-exploitation persistence, though they do not prevent the initial overflow.

The physical attack vector (AV:P) is the single most important risk modifier here: an attacker cannot exploit this remotely or even over a local network - physical proximity to the hardware is mandatory. This confines the realistic threat actors to insiders with machine access, maintenance personnel, or adversaries executing an 'evil maid' scenario against unattended systems. That said, even a mid-sized municipal IT team in gdynia should treat this as urgent for high-value endpoints such as domain controllers, HSM hosts, or air-gapped workstations where physical access by untrusted parties cannot be fully excluded. CVSS 6.8 accurately reflects the high post-access impact (C:H/I:H/A:H) tempered by the physical prerequisite. No EPSS score was provided in the source data; given the physical constraint, opportunistic mass exploitation is implausible, making real-world risk substantially lower than the impact metrics alone suggest. No KEV listing and no public POC have been identified, consistent with the high operational bar required to exploit this class of flaw.

An attacker with brief unsupervised physical access to a Windows host - for example, during a facility maintenance window or through compromise of a shared server room - connects a maliciously prepared storage device or triggers a crafted interaction with the Spaceport.sys driver interface, causing a heap overflow in the kernel pool. The overflow corrupts kernel data structures, redirecting execution to attacker-controlled shellcode running at ring 0, yielding full control of the operating system including disabling security tooling, installing a kernel-mode implant, or exfiltrating encrypted volumes. No public proof-of-concept has been identified, so exploitation currently requires bespoke kernel heap-shaping expertise.