Windows Spaceport.sys CVE-2026-50298

Physical presence at the target machine is the mandatory prerequisite - the CVSS AV:P vector confirms this vulnerability is not remotely exploitable under any configuration. The attacker requires no authentication credentials (PR:N) and no assistance from a logged-in user (UI:N), meaning exploitation can proceed against a locked but powered-on workstation or server. The vulnerable component is Spaceport.sys, which is present on Windows systems where Storage Spaces functionality is available (the driver ships by default with Windows 10, 11, and supported Server versions). No non-default configuration is required for the driver to be loaded; however, exploitation requires the ability to interact with the driver through a local interface (physical console, directly attached device). Limiting factors are significant: exploitation cannot be automated or scaled, requires undetected physical access, and is entirely blocked by standard physical security measures such as locked enclosures, device port restrictions via UEFI policy, and monitored access controls.

The CVSS 3.1 base score of 6.8 reflects the physical access requirement (AV:P), which substantially constrains real-world exploitability despite the full C:H/I:H/A:H impact triad. EPSS at 0.33% (26th percentile) independently confirms that automated or widespread exploitation is highly unlikely. SSVC reinforces this: Exploitation is none, Automatable is no, and Technical Impact is total. The combination of 'none' exploitation status and 'no automation' means this vulnerability cannot be weaponized at scale and requires deliberate, in-person targeting. The gap between the Technical Impact of 'total' and the low EPSS/Exploitation-none status is expected for physical-vector vulnerabilities - catastrophic when exploited, but gated by the hard prerequisite of physical machine access. This is a realistic threat in evil-maid attack scenarios, insider threat situations, or physical theft contexts, not in typical network-based intrusion campaigns. Priority for most enterprise environments with standard physical security controls is LOW to MEDIUM; environments with high-value targets in publicly accessible locations (kiosks, shared workstations, laptops in transit) should treat this with higher urgency.

An attacker with unsupervised physical access to a target Windows machine - for example, via an evil-maid attack against an unattended laptop or a workstation in an accessible office - interacts with the Spaceport.sys driver by attaching a specially crafted storage device or issuing crafted local IOCTL requests. The integer overflow in the driver miscalculates a buffer size, resulting in a kernel memory corruption primitive that the attacker leverages to overwrite a privileged control structure and execute arbitrary code at SYSTEM privilege. No public proof-of-concept code has been identified at time of analysis.