Google Chrome Android EUVD-2026-65884

Exploitation requires all of the following: (1) the target device must be running Google Chrome on Android prior to version 152.0.7977.65; (2) a co-installed malicious application must already be present on the device - the description states this requires social engineering to achieve, making user-assisted app installation a practical prerequisite; (3) the race condition in Chrome's Start component must be timed successfully, which the AC:H metric confirms is non-trivial and may require repeated attempts. The vendor-assigned CVSS vector states UI:N (no user interaction), but this directly conflicts with the description's social engineering requirement - defenders should treat UI:R as the realistic exploitation model pending clarification from Chromium issue 505967344. Exploitation is limited to the Android platform; AV:L confirms no remote unauthenticated path exists. The attack scope is further bounded to devices where an attacker can influence application installation.

The CVSS 8.1 score (AV:L/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H) reflects a theoretically severe outcome - full C/I/A impact with sandbox escape - but multiple signals deflate real-world priority. AC:H is correctly assigned: reliable exploitation of a race condition requires precise timing or repeated attempts. More critically, the vendor vector assigns UI:N (no user interaction), yet the description explicitly states exploitation requires 'leveraging social engineering' to place the co-installed application; this is a direct conflict that should be verified against the Chromium issue tracker entry https://issues.chromium.org/issues/505967344. EPSS at 0.15% (4th percentile) is extremely low and aligns with the absence of any KEV listing and no publicly available proof-of-concept. This is not a drop-everything priority for most organizations - it is a local, high-complexity attack requiring a controlled device environment - but Android deployments in high-value or targeted-attack contexts (e.g., enterprise mobile fleets) should treat patching as urgent.

An attacker socially engineers a target into installing a malicious Android application alongside Chrome. Once both are present on the device, the malicious app exploits the TOCTOU race window in Chrome's Start initialization sequence, winning the race to alter shared state or redirect execution before Chrome's sandbox is fully established, thereby achieving arbitrary code execution outside the sandbox in a higher-privilege Android context. No public proof-of-concept has been identified at time of analysis.