Google Chrome Android EUVD-2026-65855

Two sequential conditions are required: the attacker must first achieve code execution within Chrome's renderer process via a separate, unrelated vulnerability (a non-trivial prerequisite not addressed by this CVE alone), and the victim must visit or be navigated to a crafted HTML page that triggers the Audio UAF (user interaction required, per UI:R in the CVSS vector). The vulnerability is explicitly scoped to Chrome on Android; desktop Chrome on any platform is not indicated as affected. Factors limiting exploitation: the renderer pre-compromise requirement is a significant barrier with no single-stage unauthenticated path; SSVC confirms Automatable: no, precluding mass-scanning campaigns; user interaction is mandatory; the attack surface is Android-specific. Authentication requirements from the CVSS vector are PR:N, meaning no external credentials are required for the network delivery phase, but the renderer pre-compromise prerequisite imposes a practical complexity floor well above a typical unauthenticated attack.

The CVSS score of 8.3 (High) reflects full C/I/A impact and a scope change, but several signals substantially reduce realistic urgency: AC:H captures the multi-stage nature of the attack (renderer must already be compromised before this vulnerability can be triggered), UI:R requires the victim to visit a crafted page, and EPSS sits at just 0.41% (34th percentile), indicating very low observed exploitation interest from threat intelligence. SSVC reinforces this - Exploitation is rated none and Automatable is no, ruling out mass-exploitation tooling. The absence of any KEV listing is consistent with a vulnerability that is technically severe but operationally constrained. The CVSS Technical Impact of total (per SSVC) means successful exploitation is devastating, but the barrier to get there is non-trivial. The net picture: patch promptly as part of normal Chrome update cadence, but this does not warrant emergency out-of-band response for most organizations absent a KEV listing or POC release.

An attacker first exploits a separate renderer-level vulnerability - such as a V8 JavaScript engine bug - to gain code execution within Chrome's sandboxed renderer process on the victim's Android device. They then cause the compromised renderer to process a crafted HTML page containing malicious audio content, triggering the use-after-free in Chrome's Audio component and corrupting heap memory to redirect execution outside the sandbox. This yields arbitrary code execution at the Chrome browser process privilege level on the Android device, outside the renderer sandbox.