Windows Bluetooth Port Driver CVE-2026-70126

Exploitation requires the attacker to be on an adjacent network - specifically within Bluetooth radio range of the target (AV:A) - and the target must have Bluetooth enabled and in use. No authentication is needed (PR:N), but the attack is gated by required user interaction (UI:R), such as the victim accepting or initiating a Bluetooth connection, and by high attack complexity (AC:H), implying the attacker must satisfy conditions outside their control (e.g., winning a timing/memory-layout race). These factors - physical proximity, Bluetooth being active, user action, and the complex preconditions - are the primary limits that reduce real-world risk below the raw 7.1 score; hosts with Bluetooth disabled are not exposed.

This is a moderate, not top-tier, priority. The CVSS 3.1 base vector (CVSS:3.1/AV:A/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H = 7.1 HIGH) describes an adjacent-network (Bluetooth) issue that, while unauthenticated (PR:N), is constrained by high attack complexity (AC:H) and required user interaction (UI:R) - three real barriers that keep this well below a wormable remote-code-execution profile. The defensive signals agree: SSVC reports Exploitation=none, Automatable=no, and Technical Impact=total, so the 'total' impact is offset by the fact that it cannot be scaled or automated. No EPSS score was provided in the input, and there is no CISA KEV listing and no public proof-of-concept, so there is no public exploit identified at time of analysis. The combination of adjacency, high complexity, user interaction, and no observed exploitation makes this a patch-on-normal-cycle item for most environments rather than an emergency, despite the 'total' technical impact. Note one tension to verify: the description says 'execute code' (implying code execution) while the root weakness is an out-of-bounds read (CWE-20), which typically yields information disclosure or a crash - the C:H/I:H/A:H rating implies the read is leveraged into fuller compromise; confirm the exact impact against the Microsoft MSRC advisory.

An attacker within Bluetooth range of a target (e.g., in a shared office, airport, or conference setting) sends specially crafted Bluetooth traffic to a Windows host with Bluetooth enabled, triggering an out-of-bounds read in the Bluetooth Port Driver. Because user interaction is required and attack complexity is high, the attacker must win a race or coax the user into an action (such as accepting/initiating a Bluetooth connection) for reliable exploitation. No public exploit code is identified at time of analysis, so this remains a theoretical chain pending a working PoC.