Microsoft Bluetooth Driver CVE-2026-83760

Exploitation requires the attacker to already have local, authenticated access with at least low-level privileges (PR:L) on a Windows system running a vulnerable Bluetooth Driver build; no user interaction is needed (UI:N). The limiting factors are significant: there is no network attack surface (AV:L), the attacker must already be executing code on the target, and the impact is confined to information disclosure (C:H, I:N, A:N) - no code execution, data tampering, or denial of service results directly. The Bluetooth Driver stack must be present and reachable by the attacker's privilege level; systems with Bluetooth disabled or drivers unloaded present a reduced attack surface.

This is a moderate-severity, low-priority issue despite the HIGH confidentiality impact in the CVSS vector. The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N) confirms exploitation requires LOCAL access and existing low-level privileges (authenticated), which sharply limits real-world risk - a remote unauthenticated attacker cannot reach it. CISA's SSVC framework reinforces low urgency: Exploitation=none (no observed or public exploitation), Automatable=no (cannot be mass-scaled), Technical Impact=partial. No EPSS score was provided in the input, and the CVE is NOT on the CISA KEV list, so there is no evidence of active exploitation. No POC was indicated. The signals are internally consistent: a local info-disclosure bug (out-of-bounds read, CWE-125) scoring 5.5 with C:H but I:N/A:N means an attacker already on the machine could leak kernel/driver memory contents but cannot modify data or crash the system. This is a defense-in-depth patch-on-cycle item, not an emergency - realistic value is primarily as a secondary primitive (e.g., defeating ASLR / leaking sensitive memory) in a larger local exploit chain.

A local attacker who has already obtained low-privileged code execution on a Windows host (e.g., a standard user account or a sandboxed process) interacts with the Microsoft Bluetooth Driver to trigger an out-of-bounds read, causing the driver to return adjacent kernel memory contents. The leaked data (e.g., pointers or sensitive kernel structures) can be used to defeat memory protections and assist privilege escalation. No public exploit identified at time of analysis, and the local-access, low-privilege requirement limits this to post-compromise use.