Android Bluetooth EUVD-2026-92603

Exploitation requires the attacker to already have local code execution on the device, specifically the ability to run a low-privileged app that can reach the Bluetooth stack's LE monitoring path (PR:L, AV:L) - this is a second-stage escalation, not a remote entry point. The vulnerable code is the Microsoft vendor-extension handler (msft.cc) processing an LE monitor device event, so Bluetooth must be operational and the MSFT HCI extension path reachable on the device. Limiting factors: no remote network vector (AV:L), so it cannot be triggered directly over the air without local execution; however, there is no user-interaction requirement (UI:N) and no additional execution privileges are needed, lowering the barrier once any local foothold exists. Affected builds are Android 16, Android 16-qpr2, and Android 17 per EUVD.

This is a credible, actionable local privilege-escalation flaw rather than a high-CVSS-but-low-real-risk issue, though it is not a remote emergency. The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U, C:H/I:H/A:H, base 7.8 HIGH) describes a locally-reachable, low-complexity bug requiring low privileges and no user interaction, yielding full confidentiality/integrity/availability impact within the privileged Bluetooth process. CWE-824 (access of uninitialized pointer) combined with the description's explicit 'control-flow hijack' language indicates this is a memory-corruption primitive usable for arbitrary code execution in a privileged context - a classic Android local-EoP pattern. Exploitation status is 'no public exploit identified at time of analysis': the input provides no KEV listing, no POC flag, and no EPSS score, so there is no evidence of active exploitation or public exploit code, and no probability signal to weigh. SSVC-style reasoning: exploitation=none observed, technical impact=total (C:H/I:H/A:H), automatable=no (requires local code execution first, so it is a second-stage escalation, not a wormable remote). Conflicts/gaps to note: EPSS is absent (not merely low), so no exploitation-probability signal can be cited; KEV and POC status are both simply not provided in the input, which is normal for a freshly-published Android Bulletin entry and should not be read as 'confirmed absent.' Overall this warrants prompt patching via the monthly Android cycle but is gated behind an attacker already having local app-level execution.

A malicious or compromised low-privileged Android app running on the device triggers an LE (Bluetooth Low Energy) monitor device event that reaches the vulnerable handle_le_monitor_device_event path in msft.cc, causing the privileged Bluetooth process to dereference an uninitialized pointer. By grooming the heap/memory beforehand, the attacker turns the uninitialized pointer into a controlled value, hijacking control flow to execute code with the Bluetooth process's elevated privileges. No public exploit was identified in the provided data, and no user interaction is required.