Android Bluetooth EUVD-2026-33776

Attacker must be able to run unprivileged code on the target Android device (PR:L - a malicious or compromised app with at least basic Bluetooth-related permissions such as BLUETOOTH_CONNECT) and invoke the RFCOMM connection path that flows through bta_jv_rfcomm_connect in the native Bluetooth stack; the device must be running Android 14, 15, 16, or 16-qpr2 without the 2026-06-01 patch level. Bluetooth must be enabled on the device for the vulnerable code path to be reachable. Exploitation is limited by AV:L (no over-the-air-only attacker - code must already be on the device) and by the need for the app to hold Bluetooth permissions, but UI:N means no user prompt is required once those preconditions are met.

CVSS 7.8 with vector AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H reflects local attack vector, low complexity, low privileges, and high impact across CIA - consistent with a typical Android local EoP where a malicious app already installed on the device escalates. EPSS is 0.01% (1st percentile) and the CVE is not on CISA KEV, indicating no observed mass exploitation and limited interest in commodity exploit kits, which is normal for Android privilege-escalation bugs where exploitation is targeted (commercial spyware, forensic tooling) rather than wormable. Two signals appear to be in tension: the description references 'bonding' (a Bluetooth pairing concept that typically implies a nearby attacker) yet the CVSS vector is AV:L (local) - Google's Android scoring methodology treats apps on the device as 'local,' so the realistic scenario is a malicious local app abusing the RFCOMM API to obtain a 'secure' channel it should not have, not over-the-air exploitation; verify with the Android bulletin if intending to model an adjacent-network threat. Practical priority is moderate: patch in the next monthly Android update cycle, prioritize on devices that handle sensitive Bluetooth-paired peripherals (medical, automotive, point-of-sale).

A malicious application installed on the device (e.g., sideloaded or distributed via a trojanized app) requests an RFCOMM connection through the Bluetooth Java API in a way that triggers the logic error in bta_jv_rfcomm_connect, obtaining a connection treated as 'secure' to a previously unbonded remote endpoint. The app then leverages the resulting unprivileged-but-trusted Bluetooth channel to access data or invoke functionality that the bonding requirement was meant to gate, achieving local privilege escalation. No public exploit identified at time of analysis.