EUVD-2026-50836
GHSA-j6wg-9fv2-p5wc
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessCompromise Chrome renderer via separate bug
-
DeliveryDeliver crafted MHTML/HTML page
-
ExploitAbuse inappropriate MHTML implementation
-
ExecutionEscape renderer sandbox (S:C)
-
ImpactExecute in browser process on macOS
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V15 - Secure Coding and Architecture Protection mechanism completeness
|
| Exploitation Conditions | Exploitation requires that the attacker has ALREADY compromised the Chrome renderer process (per the description) and that the victim loads a crafted HTML/MHTML page in Chrome on macOS (CVSS UI:R). The specific trigger is Chrome's MHTML handling; the platform is limited to macOS and to Chrome builds prior to 151.0.7922.72. Limiting factors that reduce realistic risk: this is a chained second-stage flaw - it cannot be exploited standalone without a prior renderer-compromise primitive; it needs user interaction to load the page; and CISA SSVC marks it non-automatable, so it is unsuitable for opportunistic mass exploitation and more relevant to targeted, skilled attackers building a full escape chain. |
| Impact | The signals are deliberately mixed and should be weighed together. CVSS 3.1 rates this 9.6 Critical (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H), but that headline number is misleading in isolation because the description states the attacker must have ALREADY compromised the renderer process - a substantial precondition the CVSS PR:N metric does not capture. CISA's SSVC framework is more grounded: Exploitation=none (no observed attacks), Automatable=no (cannot be reliably mass-exploited), Technical Impact=total (full sandbox escape if achieved). EPSS agrees this is not an imminent mass-exploitation threat at 0.29% (21st percentile), and the CVE is NOT on CISA KEV. Note the conflict to flag explicitly: CVSS AC:L/PR:N implies easy unauthenticated access, yet the description implies a chained, high-skill precondition (renderer compromise) - verify scoring against Chrome's own High (not Critical) severity rating. Bottom line: real-world priority is moderate - patch on the normal Chrome cadence rather than as an emergency, because standalone exploitation is not possible and it only matters as the second link in an exploit chain. |
| Exploit ScenarioDerived | An attacker first uses a separate renderer-compromise bug to gain code execution inside a Chrome tab's sandboxed renderer, then serves or references a crafted MHTML/HTML page that abuses the inappropriate MHTML implementation to escape the sandbox and execute in the higher-privileged browser process on macOS. No public exploit is identified at time of analysis, and CVSS AC:L suggests the escape step itself is not technically difficult once the renderer foothold and page load (UI:R) are in place. |
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 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).
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.
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 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).
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
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
4DescriptionCVE.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)
Executive ViewAI
Google Chrome for macOS contains a critical sandbox escape vulnerability (CVE-2026-17710, CVSS 9.6) that allows attackers who have already compromised the renderer process to escalate privileges to the browser process, potentially gaining system-level access. While no public exploit exists and the probability of real-world exploitation remains low (0.3% EPSS), the vulnerability affects a ubiquitous platform and requires urgent patching across all macOS endpoints.
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 Prior to 151.0.7922.72 Security Flaws
View all 80Same 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 |
Exploit-DB