EUVD-2026-50717
GHSA-xgpf-25jc-xvgf
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessLure victim to malicious site
-
DeliveryCompromise renderer via prior bug
-
ExploitServe crafted WebSocket HTML
-
ExecutionTrigger input-validation flaw at sandbox boundary
-
PersistEscape to browser process
-
ImpactExecute code outside sandbox
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 the Chrome renderer process (a prerequisite second-stage bug), and then to get the victim to load a crafted HTML page that abuses the WebSockets code path - the CVSS UI:R confirms user interaction (navigation) is needed. The limiting factors are significant: this is not a standalone remote-code-execution vector against a pristine browser but a sandbox-escape primitive that only pays off after an initial renderer foothold, it affects only Chrome builds below 151.0.7922.72, and Google's own Medium severity rating reflects that dependency. The CVSS PR:N understates this because the 'privilege' needed is renderer control obtained via a separate vulnerability rather than an account credential. |
| Impact | The signals conflict and warrant a tempered priority. The NVD CVSS 3.1 base score is 9.6 (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H) - Critical, driven by the scope change (S:C) from sandbox escape - yet Google's own Chromium severity rating is only Medium, and the description makes clear exploitation presupposes an already-compromised renderer process, which the CVSS PR:N does not capture. In practice this is a chained-exploit component, not a standalone remote takeover. EPSS is low (0.21%, 11th percentile), there is no CISA KEV listing and no public PoC, all consistent with 'no public exploit identified at time of analysis' and no evidence of active exploitation. Net: patch on the normal Chrome cadence; it is a real sandbox-escape primitive worth closing, but the raw 9.6 overstates standalone real-world risk given the renderer-compromise prerequisite and Google's Medium internal rating. No SSVC decision data was provided in the input. |
| Exploit ScenarioDerived | An attacker first compromises the Chrome renderer through a separate bug (for example a JavaScript engine flaw) when the victim visits a malicious page, then serves crafted HTML that drives malformed WebSocket input across the sandbox boundary to escape into the more-privileged browser process. Given AV:N/UI:R, delivery is a web page the victim must load; no public PoC is currently known, so this remains a plausible chained scenario rather than a demonstrated exploit. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Jul 31, 2026
Sandbox escape in Google Chrome desktop prior to 151.0.7922.72 lets an attacker who has already compromised the renderer process break out of the browser sandbox via insufficient input validation in the WebSockets implementation, triggered by a crafted HTML page. This is a second-stage exploitation primitive rather than an initial-access bug: it requires a pre-existing renderer compromise plus user navigation to attacker content. No public exploit identified at time of analysis; EPSS is low at 0.21% (11th percentile) and it is not on CISA KEV, though Google has shipped a fixed Stable channel build.
RemediationAI
Vendor-released patch: update to Google Chrome 151.0.7922.72 or later on the Stable channel for desktop, per Google's advisory at https://chromereleases.googleblog.com/2026/07/stable-channel-update-for-desktop_0887107924.html - restart the browser to apply the staged update, and in managed fleets push the pinned version and force a relaunch so the running process actually adopts the fix. Because exploitation requires a prior renderer compromise, meaningful compensating controls target that first stage: enforce Chrome's site isolation (default), keep the OS sandbox intact, and deploy enterprise policies to reduce renderer-compromise exposure (e.g. block or sandbox untrusted plugins/extensions, enable Enhanced Safe Browsing). There is no supported way to disable the WebSocket subsystem without breaking large numbers of web applications, so the practical mitigation is prompt upgrade rather than feature disablement; users of other Chromium-based browsers should apply their vendor's build that rebases onto the fixed Chromium version.
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 Chromium's WebSocket handling, the browser-side plumbing that brokers the RFC 6455 WebSocket protocol between sandboxed renderer processes and the privileged browser (network/broker) process. The root cause is classified as CWE-20 (Improper Input Validation): data flowing from the untrusted renderer into the more-privileged process is not sufficiently validated, so a malicious renderer can supply crafted WebSocket-related input to corrupt state across the sandbox boundary. The single affected CPE is cpe:2.3:a:google:chrome (all versions below the fixed build), i.e. the desktop Chrome browser on the Stable channel; the same Chromium code is inherited by other Chromium-based browsers, though only Google Chrome is enumerated here.
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 (Medium–Critical)AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H
Requires a pre-existing renderer compromise (PR:H) and chaining plus victim navigation (AC:H, UI:R); successful escape crosses the sandbox (S:C) with full code-execution 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
4DescriptionCVE.org
Insufficient validation of untrusted input in WebSockets 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: Medium)
Executive ViewAI
Google Chrome contains a critical sandbox escape flaw affecting versions prior to 151.0.7922.72 that could allow attackers to elevate privileges from compromised browser processes to full system-level access. Although exploitation requires two prerequisites-a pre-existing renderer compromise and user navigation to attacker-controlled content-the severity and the immediate availability of a vendor patch necessitate rapid deployment to maintain browser isolation controls across your workforce.
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 Multiple 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