Windows RNDIS CVE-2026-69548

Physical access to the target Windows device is mandatory - an attacker must physically connect a malicious USB device that presents itself as an RNDIS network adapter. Windows must auto-load the RNDIS driver upon device connection, which occurs by default on Windows systems when a USB device advertises RNDIS class. No user authentication, account credentials, or privileged access is required once physical contact with the machine is achieved. Exploitation is blocked by: locked screen with USB enforcement policies, USB device allowlisting, physical security (locked rooms, kensington locks on ports), or disabling USB ports in BIOS/UEFI. The vulnerability does not affect network-connected scenarios; the attack cannot be performed remotely.

The CVSS 3.1 vector AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N correctly reflects the fundamental constraint of this vulnerability: physical machine access is required. This dramatically limits the attacker pool to insiders, supply-chain actors, or opportunistic access in unattended device scenarios (kiosks, conference rooms, hotel business centers). The impact is limited to information disclosure - no integrity or availability impact is assessed. EPSS data was not provided, but the physical vector alone places practical exploitation probability very low for most enterprise environments. No active exploitation is confirmed by CISA KEV, and no public proof-of-concept code has been identified. The broad affected version range (Server 2012 through current Windows 11 releases) increases patch surface but does not change the physical prerequisite. Overall priority is low to medium: apply the Microsoft patch as part of routine Patch Tuesday maintenance, but this does not warrant emergency out-of-band response.

An attacker with brief unattended access to a Windows workstation (e.g., a conference room laptop or hotel business center PC) connects a purpose-built malicious USB device configured to impersonate an RNDIS network adapter. When Windows auto-loads the RNDIS driver and processes the device's malformed control messages, the heap overflow triggers and the attacker's device reads back heap memory contents, potentially capturing sensitive data such as credentials, keys, or session tokens resident in memory. No proof-of-concept code has been publicly identified for this specific vulnerability.