Severity by source
Sources disagree (Low–Critical)AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H
AC:H because a prior renderer compromise plus crafted Mojo messages are required; UI:R for loading the page; S:C and C/I/A:H reflect full escape from sandbox to the browser process.
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 VectorNVD
Lifecycle Timeline
4DescriptionNVD
Insufficient policy enforcement in Mojo in Google Chrome 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 desktop before 150.0.7871.47 lets an attacker who has already compromised the renderer process bypass Mojo IPC policy enforcement and break out of the sandbox using a crafted HTML page. This is a second-stage flaw in the Mojo inter-process communication layer rather than an initial-access bug, and Google itself rated the Chromium security severity as Low despite the NVD CVSS of 9.6. No public exploit identified at time of analysis, and EPSS is low (0.17%, 7th percentile).
Technical ContextAI
Mojo is Chromium's core inter-process communication (IPC) framework that mediates messages between the sandboxed renderer processes and the more privileged browser process. The weakness maps to CWE-602 (Client-Side Enforcement of Server-Side Security): a security policy that should be enforced by the trusted browser-side endpoint is instead insufficiently validated, so a renderer that an attacker already controls can send crafted Mojo messages that the browser process wrongly honors. Because the renderer is intentionally treated as untrusted, any policy that Mojo fails to re-check on the privileged side becomes a boundary-crossing primitive, in this case enabling escape from the renderer sandbox into the higher-privilege browser context.
RemediationAI
Vendor-released patch: update Google Chrome to 150.0.7871.47 or later on all desktop platforms, per the Chrome Releases advisory (https://chromereleases.googleblog.com/2026/06/stable-channel-update-for-desktop_0175352312.html); most installations will pick this up automatically, so verify auto-update is enabled and relaunch the browser to apply it, since a running instance stays vulnerable until restarted. There is no vendor-supplied configuration workaround for the Mojo flaw itself; because exploitation requires a prior renderer compromise, the practical compensating control until patching completes is to reduce renderer-compromise exposure - enforce Site Isolation (default on desktop), restrict browsing of untrusted content, and deploy enterprise policies to keep Chrome current. These measures reduce the chance of the first-stage compromise this bug depends on but do not close the sandbox-escape gap, so patching remains the only complete fix.
Same 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
EUVD-2026-40796
GHSA-8gcq-7px3-66qq