EUVD-2026-40742
GHSA-fhx7-pv78-v4ww
Severity by source
Sources disagree (Low–Critical)AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H
Requires a pre-existing renderer compromise plus victim interaction, so AC:H and UI:R; the sandbox escape crosses the isolation boundary (S:C) with full C/I/A impact at browser-process level.
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: google
Lifecycle Timeline
4DescriptionCVE.org
Insufficient validation of untrusted input in Device Trust in Google Chrome on Windows prior to 150.0.7871.47 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)
AnalysisAI
Sandbox escape in Google Chrome on Windows prior to 150.0.7871.47 lets a remote attacker who has already compromised the renderer process break out of the browser sandbox by feeding crafted input to the Device Trust component via a malicious HTML page. NVD scores this 9.6 (Critical) while Google rates the Chromium security severity as Low, and there is no public exploit identified at time of analysis. EPSS is very low at 0.17% (7th percentile), and it is not listed in CISA KEV.
Technical ContextAI
The flaw sits in Chrome's Device Trust feature on Windows, which handles enterprise device attestation/verification signals. The root cause is CWE-20 (Improper Input Validation): the component insufficiently validates untrusted input reachable from a compromised renderer, allowing a crafted HTML page to drive it into an unsafe state that crosses the renderer sandbox boundary. Chrome's multi-process architecture isolates web content in a low-privilege renderer sandbox, so a sandbox escape defeats that isolation and yields execution at the higher-privilege browser-process level. The EUVD/NVD data identifies the affected product as Google Chrome builds below 150.0.7871.47 on Windows.
RemediationAI
Vendor-released patch: update Google Chrome to 150.0.7871.47 or later on Windows via the Stable Channel update (https://chromereleases.googleblog.com/2026/06/stable-channel-update-for-desktop_0175352312.html); most managed and consumer installs auto-update, so ensure the browser is fully restarted to apply the new build and push the release through enterprise update policies. If immediate patching is not possible, the practical compensating control is to reduce renderer-compromise exposure - restrict browsing to trusted sites, keep site isolation enabled, and in enterprise environments consider disabling or tightly scoping the Device Trust / device-attestation feature via policy since it is the vulnerable surface, accepting the trade-off of losing device-trust-based access decisions. Because exploitation requires a prior renderer compromise, aggressively patching other Chrome renderer bugs and enforcing timely updates is the highest-value control.
Same 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 Tumbleweed | Fixed |
| SUSE Package Hub 15 SP7 | Affected |
Share
External POC / Exploit Code
Leaving vuln.today