Severity by source
AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H
Raised to AC:H because a successful escape presupposes prior renderer compromise plus a crafted page; scope Changed as the sandbox boundary is crossed, with full C/I/A impact on the browser process.
Primary rating from Vendor (Chrome).
CVSS VectorVendor: Chrome
Lifecycle Timeline
5DescriptionCVE.org
Inappropriate implementation in MHTML in Google Chrome on Mac 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)
AnalysisAI
Sandbox escape in Google Chrome for macOS prior to 151.0.7922.72 lets an attacker who has already compromised the renderer process break out of the sandbox and reach the more-privileged browser process by loading a crafted HTML page that abuses Chrome's MHTML handling. It is rated High by Chromium and carries a CVSS 9.6 (scope-changed) score, but exploitation is a second-stage step that presupposes prior renderer compromise. There is no public exploit identified at time of analysis, and EPSS is low at 0.29% (21st percentile).
Technical ContextAI
The flaw lives in Chrome's MHTML (MIME HTML) subsystem, the single-file web-archive format that bundles an HTML page and its resources into one MIME multipart document. It is classified as CWE-693 (Protection Mechanism Failure), meaning a security control - here the renderer sandbox boundary that isolates untrusted web content from the browser process - is implemented inappropriately rather than a classic memory-corruption bug. The affected component is the Chromium/Blink rendering engine as shipped in Google Chrome on macOS (cpe:2.3:a:google:chrome). Because MHTML parsing crosses the renderer/browser trust boundary, an already-compromised renderer can leverage the inappropriate implementation to influence privileged browser-side behavior, which is why the CVSS scope is marked Changed (S:C).
RemediationAI
Vendor-released patch: upgrade Google Chrome on macOS to 151.0.7922.72 or later via the Stable Channel update (https://chromereleases.googleblog.com/2026/07/stable-channel-update-for-desktop_0887107924.html); Chrome normally auto-updates, so ensure the browser is fully closed and relaunched to apply the new build, and confirm the version under chrome://settings/help. There is no vendor-specified standalone workaround, but because exploitation requires a compromised renderer, the practical compensating controls are those that harden against the first-stage renderer compromise: keep the renderer sandbox enabled (do not launch Chrome with --no-sandbox), enforce Site Isolation, and where policy permits enable Enhanced Safe Browsing to reduce exposure to hostile pages - the trade-off is that none of these fully close the specific MHTML issue, so patching remains the only complete fix. Enterprises can also restrict opening untrusted .mht/.mhtml archives, at the cost of breaking legitimate saved-web-archive workflows.
Same weakness CWE-693 – Protection Mechanism Failure
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 |
Share
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-50836
GHSA-j6wg-9fv2-p5wc