Google Chrome EUVD-2026-65833

Two conditions must be met simultaneously for exploitation: the target must be running Google Chrome on Android prior to version 152.0.7977.65, and the attacker must have ALREADY achieved code execution inside Chrome's renderer process via a separate, distinct vulnerability - the WebAppInstalls authorization bypass is not independently exploitable from a standard web attacker position. Additionally, user interaction is required (UI:R): the victim must navigate to or load a crafted HTML page controlled by the attacker. The renderer compromise is the primary and significant practical barrier, restricting exploitation to sophisticated, multi-stage attack chains. Exploitation is scoped to the Android platform based on the CVE description; desktop Chrome is not identified as affected. The specific class of sensitive information accessible via the bypass is not detailed in available sources.

The CVSS 3.1 score of 5.3 (Medium) with vector AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N reflects the chained, multi-step nature of this attack. AC:H is the critical signal - exploitation of THIS authorization bypass requires a renderer process that has ALREADY been compromised by a separate, independent vulnerability, making autonomous exploitation highly improbable. The C:H confidentiality rating describes what the authorization bypass enables once the attacker is inside the renderer, but I:N and A:N confirm there is no write or denial-of-service capability. The EPSS score of 0.38% at the 30th percentile is consistent with this complexity profile and indicates no observed uptick in exploitation attempts. The absence of a CISA KEV listing and the lack of any identified public proof-of-concept further support treating this as a medium-priority patch rather than an emergency. The 'Authentication Bypass' tag in the source data aligns with the CWE-862 classification. One signal tension worth noting: PR:N in the CVSS vector suggests no authentication is required, which is technically accurate for the authorization bypass itself, but does not convey that a renderer compromise is a prerequisite - the base score therefore slightly overstates standalone exploitability.

An attacker first leverages a separate renderer-level vulnerability in Chrome for Android to achieve code execution within the sandboxed renderer process, then serves a crafted HTML page that causes the compromised renderer to invoke the WebAppInstalls IPC path without triggering a valid authorization check in the browser process, resulting in sensitive information being returned to the attacker-controlled renderer context. No public proof-of-concept has been identified for this specific authorization bypass at time of analysis.