Windows USB Driver EUVD-2026-72966

Exploitation requires a valid Windows user account with at minimum standard user (low) privilege and the ability to execute local code on the target system - confirmed by CVSS PR:L and AV:L. No USB peripheral device needs to be physically attached; the vulnerability is in the software driver's IOCTL handling path, not USB hardware enumeration. The USB driver stack is loaded by default on all affected Windows installations, meaning no non-default configuration is required. Exploitation is specifically constrained by: the requirement for local code execution (no network-based exploitation path exists per AV:L), and the need for at least a low-privilege account (unauthenticated or anonymous network exploitation is not possible). Scope is unaffected (S:U), so the read does not directly escape the driver's security boundary, limiting direct impact to confidentiality.

The CVSS 5.5 medium rating accurately characterizes the technical risk floor: exploitation requires local code execution and a low-privilege account (PR:L, AV:L), which substantially limits the attack surface compared to remotely exploitable flaws. However, kernel information disclosure vulnerabilities of this type carry disproportionate real-world weight as enablers - leaked kernel addresses defeat KASLR, a foundational Windows exploit mitigation, making this flaw a common intermediate link in local privilege escalation chains rather than an end-goal on its own. No EPSS score was provided in the input data; its absence should not be treated as low risk. No CISA KEV listing or public exploit code has been identified, suggesting opportunistic mass exploitation is not currently occurring. The extremely broad affected version footprint (19 distinct version/SKU combinations spanning 14 years of Windows releases) means the vulnerable population is very large, amplifying aggregate risk even if per-instance severity is moderate.

A low-privilege user authenticated to a Windows system (via RDP, a compromised service account, or direct console access) opens a handle to the USB driver and submits a specially crafted IOCTL or device request. The out-of-bounds read causes the driver to return adjacent kernel pool memory to the caller's user-space buffer, leaking kernel addresses or sensitive data. The attacker uses leaked KASLR offsets to calculate kernel base addresses, then chains this disclosure into a separate privilege escalation exploit to achieve SYSTEM-level access.