EUVD-2026-50807
GHSA-5mm6-fj7r-pv27
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessLure victim to crafted HTML page
-
DeliveryExploit separate renderer bug for sandbox foothold
-
ExploitSend malformed WebAuthn input from renderer
-
ExecutionTrigger input-validation flaw in browser process
-
ImpactEscape sandbox to browser-process privileges
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V2 - Validation and Business Logic Input validation, allowlisting
|
| Exploitation Conditions | Exploitation requires the attacker to have ALREADY compromised Chrome's renderer process on the target Android device - this is a chained sandbox-escape bug, not a standalone entry point, and cannot be triggered without that prior foothold. The specific trigger is crafted untrusted input sent through the Web Authentication (WebAuthn) component via a malicious HTML page, and the CVSS UI:R metric confirms victim interaction (visiting the attacker's page) is needed. It is limited to Google Chrome on Android below 151.0.7922.72; patched builds are not exploitable. The dependence on a separate renderer exploit is the dominant limiting factor and is why real-world exploitation is expected to be targeted rather than widespread. |
| Impact | The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H = 9.6) reflects network reachability, low complexity, no privileges, a scope change (sandbox boundary crossed), and full CIA impact. That headline number overstates standalone risk: the description explicitly requires 'a remote attacker who had compromised the renderer process,' meaning this bug is not exploitable on its own and must be paired with a separate renderer RCE - a nuance the PR:N metric does not capture. That gating condition aligns with the low EPSS score (0.34%, 27th percentile) and the absence of KEV listing or public POC, indicating this is not seen in mass exploitation. It is nonetheless a genuine priority for any exploit chain author, since sandbox escapes are the second half of full Chrome compromises and are frequently weaponized in targeted mobile attacks; browser sandbox escapes historically attract advanced actors even when EPSS is low. Bottom line: high theoretical severity, meaningful in chained/targeted contexts, but low likelihood of opportunistic mass exploitation, and easily mitigated because a patched build already exists. |
| Exploit ScenarioDerived | An attacker first lures a victim to a malicious web page that exploits a separate renderer-process vulnerability to gain code execution inside Chrome's sandbox on Android. From that foothold, the attacker issues crafted WebAuthn requests with malformed untrusted input that the browser process fails to validate, escaping the sandbox to run with the browser's higher privileges. No public POC is currently identified, and the low CVSS attack complexity means the escape step is reliable once the renderer is owned. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Jul 30, 2026
Sandbox escape in Google Chrome for Android before 151.0.7922.72 lets an attacker who has already compromised the renderer process break out of the browser sandbox by feeding crafted untrusted input to the Web Authentication (WebAuthn) component. Rated High severity by Chromium and scored CVSS 9.6, it is a second-stage bug chained after an initial renderer exploit rather than a standalone remote compromise. No public exploit identified at time of analysis, and EPSS exploitation probability is low at 0.34% (27th percentile).
RemediationAI
Vendor-released patch: update Google Chrome for Android to 151.0.7922.72 or later, per the Chrome Releases advisory (https://chromereleases.googleblog.com/2026/07/stable-channel-update-for-desktop_0887107924.html); on Android this is delivered through the Google Play Store, so ensure automatic app updates are enabled and force-update managed fleets via MDM. There is no configuration workaround for the WebAuthn code path itself, but because exploitation requires a prior renderer compromise, the practical compensating control is to prevent that first stage: keep Chrome fully current, avoid untrusted sites, and in managed environments use enterprise policies to restrict browsing to trusted destinations - with the trade-off of reduced usability. Disabling passkeys/WebAuthn is not a supported per-feature toggle and would break legitimate strong-authentication flows, so patching is the only reliable fix. Track the technical fix at https://issues.chromium.org/issues/516813184.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The flaw lives in Chrome's Web Authentication (WebAuthn) implementation, the browser API that brokers FIDO2/passkey and hardware-security-key ceremonies between web pages and the platform. On Android, WebAuthn requests cross from the sandboxed renderer to higher-privilege browser-process code that handles credential and authenticator data. The root cause is CWE-20 (Improper Input Validation): the trusted browser-side code insufficiently validates data arriving from the untrusted renderer, so a renderer under attacker control can supply malformed input that the privileged process mishandles. The affected code path is identified by Chromium issue 516813184. The single CPE (cpe:2.3:a:google:chrome:*) is version-generic, but the description scopes impact specifically to the Android build prior to 151.0.7922.72.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H
Delivered via a web page (AV:N, UI:R) with no target credentials (PR:N); sandbox breakout yields a scope change (S:C) and full browser-process compromise (C/I/A:H), though a prior renderer exploit is a practical prerequisite.
Primary rating from Vendor (Chrome).
CVSS VectorVendor: Chrome
Lifecycle Timeline
4DescriptionCVE.org
Insufficient validation of untrusted input in Web Authentication in Google Chrome on Android prior to 151.0.7922.72 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High)
Executive ViewAI
Google Chrome for Android versions before 151.0.7922.72 contain a critical sandbox escape vulnerability that could allow attackers to fully compromise Android devices, though only after first compromising the browser through another vulnerability. No public exploit has been identified at time of analysis, and exploitation probability remains low at 0.3%. Organizations supporting Android should prioritize upgrading Chrome to prevent sophisticated multi-stage attacks that could lead to data theft and device takeover.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Related Vulnerabilities in Google Chrome Prior to 151.0.7922.72 Security Flaws
View all 80Same weakness CWE-20 – Improper Input Validation
View allSame technique Information Disclosure
View allVendor StatusVendor
SUSE
Severity: Critical| Product | Status |
|---|---|
| SUSE Package Hub 15 SP7 | Fixed |
| openSUSE Leap 16.0 | Fixed |
| SUSE Package Hub 15 SP7 | Affected |
Exploit-DB