EUVD-2026-50928
GHSA-2wqv-r9pg-89qm
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessCompromise renderer process via prior exploit
-
DeliveryServe crafted HTML to Google Lens
-
ExploitTrigger improper input validation (CWE-20)
-
ExecutionEscape browser sandbox
-
ImpactGain browser-process control on host
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 that the attacker has ALREADY compromised the Chrome renderer process - this is a second-stage sandbox escape, not a standalone remote bug - and additionally requires a crafted HTML page processed through the Google Lens code path plus user interaction (UI:R, e.g. visiting/interacting with the malicious page). The prerequisite renderer compromise is the dominant limiting factor: without a working renderer exploit to chain from, this vulnerability cannot be reached, which is consistent with Chromium's 'Low' severity rating and the very low EPSS. It affects Chrome desktop before 151.0.7922.72. |
| Impact | The signals are sharply contradictory and must be reconciled. The published CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H = 9.6 Critical) reads as a near-worst-case network bug, but the description explicitly states the attacker must have 'compromised the renderer process' first - meaning PR:N/AC:L overstates the true ease, since this is a chained second-stage escape, not standalone remote code execution. Reinforcing the lower real-world risk: Chromium's own security team rated the severity 'Low', EPSS is only 0.16% (6th percentile), there is no KEV listing, and no public exploit was identified. This is therefore a high-CVSS-but-moderate-real-risk issue: dangerous as the second link in an exploit chain (which is why sandbox escapes matter), but not independently exploitable and not a same-day patch emergency absent evidence of an accompanying renderer bug. Note the explicit conflict: CVSS scores it Critical while the vendor scores it Low and EPSS scores it near-negligible - verify prioritization against your own Chrome exposure and chaining risk. |
| Exploit ScenarioDerived | An attacker first lands a separate renderer-process exploit - for example via a malicious ad or compromised site the victim visits - then serves a crafted HTML page that abuses Google Lens's unvalidated input handling to escape the sandbox and gain browser-process-level control on the host. No public exploit code was identified, and the chain requires the victim to interact with attacker-controlled content (UI:R). |
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's Google Lens component (versions prior to 151.0.7922.72) lets an attacker who has already compromised the renderer process break out of the browser sandbox using a crafted HTML page. The flaw is a second-stage privilege boundary bypass rather than an initial-access bug: it requires a pre-existing renderer compromise to reach, and Google's own Chromium team rated its security severity as Low despite the 9.6 CVSS. No public exploit identified at time of analysis, and EPSS is very low at 0.16% (6th percentile).
RemediationAI
Vendor-released patch: update Google Chrome to 151.0.7922.72 or later via the desktop Stable channel (restart the browser to apply, since Chrome stages updates but only activates them on relaunch); see https://chromereleases.googleblog.com/2026/07/stable-channel-update-for-desktop_0887107924.html. In managed fleets, push the update through your enterprise update policy or endpoint management and verify the running version rather than the installed version. As a compensating control until the update is applied, prioritize patching the renderer-level bugs this escape would be chained to (keeping Chrome fully current closes both), and enforce Chrome's site isolation and sandbox settings so a renderer compromise remains harder to achieve; there is no documented feature-level toggle to disable only Google Lens as a mitigation, so the practical control is simply completing the browser update.
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 affected technology is the Google Lens feature integrated into the Chromium/Chrome browser, which runs across the browser's multi-process sandbox architecture. Chrome isolates untrusted web content in low-privilege renderer processes; a sandbox escape crosses that trust boundary to reach the higher-privileged browser process and, effectively, the host. The root cause is CWE-20 (Improper Input Validation): Google Lens insufficiently validates untrusted input passed to it, allowing a malicious/compromised renderer to manipulate that path to break isolation. The CPE cpe:2.3:a:google:chrome:*:*:*:*:*:*:*:* confirms the affected product is the Chrome application itself.
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
Sources disagree (Low–Critical)AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H
Sandbox escape requires a pre-existing renderer compromise plus a crafted page and user interaction, so AC:H and UI:R; escaping the sandbox is a scope change (S:C) with full host impact.
vuln.today treats the vendor’s rating as authoritative. A higher third-party CVSS (e.g. CISA-ADP) is shown for transparency but does not drive the headline severity.
CVSS VectorVendor: Chrome
Lifecycle Timeline
3DescriptionCVE.org
Insufficient validation of untrusted input in Google Lens in Google Chrome 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: Low)
Executive ViewAI
Google Chrome versions before 151.0.7922.72 contain a privilege escalation flaw that allows attackers who have compromised a user's browser to gain complete system access. For organizations where employees encounter untrusted content or where browsers may already be compromised, this vulnerability chains browser exploitation into full system compromise. Rapid patching is critical to prevent this escalation path.
Apply vendor patch: Chrome 151.0.7922.72 or later. Interim controls while deployment progresses: monitor for renderer process crashes and anomalies, implement network-based content filtering to reduce browser compromise likelihood, and isolate critical workflows to air-gapped or restricted endpoints.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
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 Implementation and Policy Flaws
View all 50Same 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