Google Android EUVD-2026-92619

Exploitation requires a locally installed, low-privilege application on the Android device that can repeatedly drive the AVRCP remote-control code path (handle_app_val_response in btif_rc.cc) to win a timing race; no user interaction is required. Limiting factors: the attacker must already have code running on the device (PR:L, AV:L - no remote or network reach), and the CWE-362 race condition carries high attack complexity (AC:H), meaning success depends on repeatedly hitting a narrow timing window rather than a deterministic single-shot trigger. Affected scope is limited to Android 16, 16-qpr2, and 17; patched builds in the October 2026 bulletin eliminate the window.

Signals are consistent and point to a genuine but non-urgent priority. The CVSS 3.1 vector (AV:L/AC:H/PR:L/UI:N) describes a local, high-complexity flaw requiring low (non-privileged app) privileges, scoring 7.0 - the C:H/I:H/A:H impact reflects total compromise of the Bluetooth stack's privileged context. This aligns with CISA SSVC, which rates Technical Impact as 'total' but Exploitation as 'none' and Automatable as 'no' - the latter is expected for a CWE-362 race condition, which is inherently timing-dependent and not reliably scriptable at scale. There is no CISA KEV listing and no public exploit referenced, so exploitation status is 'no public exploit identified at time of analysis.' EPSS is not provided in the input, so probabilistic exploitation likelihood could not be factored in. The AC:H rating is well-justified: winning the race in handle_app_val_response requires precise timing, which materially lowers real-world exploitability versus the raw 7.0 score. Net: a credible local privilege-escalation path meriting routine patching via the monthly Android bulletin cycle, not emergency response.

A malicious or compromised low-privilege app installed on an Android device repeatedly exercises the AVRCP Bluetooth path to trigger the race condition in handle_app_val_response, winning the timing window to corrupt memory in the privileged Bluetooth process. Because no user interaction is needed and the attacker only needs an app running locally, successful exploitation yields code execution in the Bluetooth stack's context and escalation of privilege. No public proof-of-concept exploit is identified at time of analysis, and the high attack complexity means exploitation requires repeated attempts to win the race.