This is a lockpick for the lobby door, not the master key to the whole building
CVE-2026-10956 is a use-after-free in Chrome's MimeHandlerView, affecting Chrome desktop builds before 149.0.7827.53 on Linux and before 149.0.7827.53/.54 on Windows/macOS. In plain English: attacker-controlled web content can make Chrome touch memory after it has been freed, which can let the attacker run code inside the browser's sandboxed process after a user visits or renders crafted content. Based on Chrome's advisory wording and the component involved, this looks like a renderer/content-handling bug, not a direct OS-level takeover.
Google's HIGH 8.8 baseline is technically reasonable in a vacuum because the bug is remotely reachable and sits in a massively deployed client. In the real world, though, the biggest fact is the one defenders care about: the stated impact is code execution inside a sandbox, which means an attacker still needs a second primitive for a full workstation compromise. Add the lack of KEV, lack of public exploit evidence, and a very low EPSS (0.0008), and this lands lower on an enterprise patch queue than internet-facing edge flaws or sandbox-escape chains.
4 steps from start to impact.
Deliver crafted web content to Chrome
MimeHandlerView memory handling. The delivery vehicle is most likely a hostile webpage or embedded object rendered by a vulnerable Chrome build. No authentication is needed against the browser itself.- Target is running Chrome prior to 149.0.7827.53/.54
- User browses to attacker-controlled content or content the attacker can influence
- The vulnerable code path in
MimeHandlerViewis actually reached
- This is UI:R; the victim must open or render the content
- Enterprise filtering, Safe Browsing, URL isolation, and mail/web gateways can reduce first contact
- Not every browsing session reaches
MimeHandlerView; the exploit must hit the right parser/handler path
MimeHandlerView path. Web proxies, browser telemetry, and EDR may catch suspicious delivery or crash spikes, but coverage is indirect.Trigger the use-after-free
- A working exploit primitive for this exact Chrome build family
- Heap grooming or timing that is stable enough for the target platform
- Chrome memory corruption exploits are noisy during development and can degrade into crashes rather than code execution
- Google often withholds bug details until users update, which slows copycat weaponization
- Cross-platform reliability is hard; Windows, macOS, and Linux builds diverge
Gain code execution in the renderer sandbox
- Exploit reliability sufficient to avoid simple denial-of-service behavior
- The target's browser hardening features do not break the exploit chain
- The sandbox sharply limits filesystem, device, and OS access
- Many high-value follow-on actions require a second bug or a credential/token objective that exists only in-browser
- EDR often has good visibility into unusual browser memory corruption outcomes even when prevention is imperfect
Chain to real endpoint impact
- A second vulnerability, misconfiguration, or in-browser objective worth stealing
- Access to an interesting user session, SaaS token, or sensitive app workflow
- No second-stage bug is included in this CVE
- Modern browsers, OS sandboxes, and EDR reduce direct breakout paths
- Blast radius depends heavily on who the user is and what apps are open
The supporting signals.
| In-the-wild status | No public exploitation evidence located as of 2026-06-05. Google did not mark this as exploited in the release note, and I found no KEV entry. That is a meaningful downgrade from the vendor baseline. |
|---|---|
| KEV status | Not listed in CISA KEV as of 2026-06-05. For prioritization, that removes the strongest urgency signal defenders usually get for browser bugs. |
| Proof-of-concept availability | No public PoC found in the Chrome advisory, the linked Chromium issue, or obvious GitHub searches. *Inference:* restricted bug details and absent exploit chatter suggest copycat weaponization is not immediate. |
| EPSS | 0.0008 from the user-supplied intel. That is extremely low in practical terms; percentile was not independently verified from a primary EPSS response during this assessment. |
| CVSS vector meaning | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H means remote and unauthenticated, but user interaction is required and the scope stays unchanged. The hidden real-world limiter is not in CVSS: Chrome says code execution is inside a sandbox. |
| Affected versions | Chrome desktop before 149.0.7827.53 on Linux and before 149.0.7827.53/.54 on Windows and macOS. The Google desktop stable release published on 2026-06-02 is the fix train. |
| Fixed versions | Upgrade to 149.0.7827.53 or later on Linux and 149.0.7827.53/.54 or later on Windows/macOS. In enterprise terms, validate the actual binary version on endpoints, not just the package channel assignment. |
| Exposure/scanning reality | Internet census tools like Shodan/Censys/FOFA are poor fit for this CVE because Chrome is a client-side browser, not a server you meaningfully count from the edge. Exposure should be measured from endpoint inventory/MDM/EPM, not internet-facing scan data. |
| Disclosure and reporting | Disclosed 2026-06-04; Chrome's stable fix shipped 2026-06-02. The specific bug was reported by Google on 2026-04-25 in the release note. |
| Population and blast radius | Chrome is ubiquitous, which keeps this above LOW, but the blast radius of this single CVE is narrower than the install base implies because the attacker still lands inside the renderer sandbox unless they have a second-stage escape or token objective. |
noisgate verdict.
The decisive factor is sandbox confinement: the disclosed impact is code execution inside Chrome's sandboxed process, not direct host compromise. That sharply reduces standalone enterprise blast radius unless this bug is paired with a sandbox escape, token theft opportunity, or another post-renderer stage.
Why this verdict
- Start at 8.8, then cut for sandbox reality: vendor scoring assumes remote code execution is inherently urgent, but the public description says execution is inside a sandbox, which materially lowers standalone impact.
- UI:R is real friction: this requires the attacker to win a user-browsing event or content-render event. That implies phishing, malvertising, compromised sites, or another delivery channel rather than direct reachability.
- No exploitation signal: no KEV, no public Google statement of in-the-wild abuse, no obvious public PoC, and a very low EPSS 0.0008 all push this down the queue.
- Population is broad, but reachability is narrower: Chrome is everywhere, yet only vulnerable builds that actually hit the
MimeHandlerViewpath are candidates. That is less deterministic than an externally exposed VPN or web appliance flaw. - Modern controls help after first stage: EDR, browser isolation, Safe Browsing, and identity telemetry can still blunt follow-on actions even if renderer compromise occurs.
Why not higher?
This is not scored higher because the public impact stops at sandboxed browser code execution. There is no public second-stage sandbox escape, no KEV listing, and no exploitation evidence that would justify treating this like a full remote workstation takeover. For a 10,000-host patch queue, that matters.
Why not lower?
This is not LOW because it is still a remote memory-corruption bug in Chrome, a massively deployed client that routinely faces hostile content. If weaponized, it can still compromise the browser process, abuse sessions, and serve as stage one in a broader chain.
What to do — in priority order.
- Enforce Chrome auto-update compliance — Make sure managed endpoints are actually receiving Chrome 149.0.7827.53/.54 or later and are not pinned on stale channels. Because this is a MEDIUM noisgate verdict, there is no mitigation SLA; do this as routine hygiene while driving patch closure within the 365-day remediation window.
- Prioritize high-risk user groups for browser isolation — Apply or verify browser isolation for admins, finance, executives, and users who routinely open untrusted links or documents. Isolation matters here because the exploit's advertised impact is inside the browser sandbox, and isolation further shrinks useful attacker outcomes; with a MEDIUM verdict, there is no mitigation SLA, so align this to your standard hardening cycle.
- Hunt for version laggards in unmanaged or exception fleets — Focus on VDI gold images, kiosks, lab systems, developer workstations with update deferrals, and offline laptops. These are the places where Chrome auto-update assumptions usually fail, and for a MEDIUM issue you should close those gaps as part of the remediation plan rather than invoking an emergency change.
- Monitor browser crash and child-process anomalies — Use EDR and browser telemetry to look for repeated renderer crashes, unusual command lines, or suspicious browser-spawned processes around suspicious browsing events. This will not replace patching, but it improves your odds of catching exploit development or a chained attack while you work through normal remediation.
- A perimeter WAF does not meaningfully help; this is a client-side browser flaw triggered by content rendering, not your server parsing hostile input.
- Relying on network vulnerability scanners alone is weak; they can tell you Chrome is outdated on some managed assets, but they do not prove the vulnerable
MimeHandlerViewpath is reachable or blocked. - Assuming Chrome auto-update solved everything is dangerous in enterprise fleets; kiosks, gold images, suspended laptops, and policy-pinned channels are where stale versions survive.
Crowdsourced verification payload.
Run this on the target endpoint itself or via your software-distribution/remote-execution tooling. Invoke it as python3 check_chrome_cve_2026_10956.py on macOS/Linux or py check_chrome_cve_2026_10956.py on Windows; no admin rights are required, but the script needs permission to read Chrome executable metadata in standard install paths.
#!/usr/bin/env python3
# Check exposure to CVE-2026-10956 (Chrome MimeHandlerView UAF)
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import subprocess
import sys
from typing import Optional, Tuple
WIN_SAFE = (149, 0, 7827, 54) # treat .54 as patched for Win/macOS per vendor note
MAC_SAFE = (149, 0, 7827, 54)
LINUX_SAFE = (149, 0, 7827, 53)
def parse_version(text: str) -> Optional[Tuple[int, int, int, int]]:
m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', text)
if not m:
return None
return tuple(int(x) for x in m.groups())
def cmp_ver(a, b):
return (a > b) - (a < b)
def get_version_from_command(cmd):
try:
p = subprocess.run(cmd, capture_output=True, text=True, timeout=10)
out = (p.stdout or '') + ' ' + (p.stderr or '')
return parse_version(out)
except Exception:
return None
def windows_version() -> Optional[Tuple[int, int, int, int]]:
candidates = [
os.path.join(os.environ.get('ProgramFiles', r'C:\Program Files'), 'Google', 'Chrome', 'Application', 'chrome.exe'),
os.path.join(os.environ.get('ProgramFiles(x86)', r'C:\Program Files (x86)'), 'Google', 'Chrome', 'Application', 'chrome.exe'),
os.path.join(os.environ.get('LocalAppData', ''), 'Google', 'Chrome', 'Application', 'chrome.exe'),
]
for path in candidates:
if path and os.path.exists(path):
try:
cmd = [
'powershell', '-NoProfile', '-Command',
f"(Get-Item '{path}').VersionInfo.ProductVersion"
]
v = get_version_from_command(cmd)
if v:
return v
except Exception:
pass
return None
def mac_version() -> Optional[Tuple[int, int, int, int]]:
app = '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'
if os.path.exists(app):
return get_version_from_command([app, '--version'])
return None
def linux_version() -> Optional[Tuple[int, int, int, int]]:
commands = [
['google-chrome', '--version'],
['google-chrome-stable', '--version'],
['chromium-browser', '--version'],
['chromium', '--version'],
]
for cmd in commands:
v = get_version_from_command(cmd)
if v:
return v
return None
def main():
system = platform.system().lower()
version = None
safe = None
product = 'Google Chrome/Chromium-like browser'
if 'windows' in system:
version = windows_version()
safe = WIN_SAFE
product = 'Google Chrome on Windows'
elif 'darwin' in system:
version = mac_version()
safe = MAC_SAFE
product = 'Google Chrome on macOS'
elif 'linux' in system:
version = linux_version()
safe = LINUX_SAFE
product = 'Google Chrome/Chromium on Linux'
else:
print(f'UNKNOWN: unsupported OS {platform.system()}')
sys.exit(2)
if not version:
print(f'UNKNOWN: could not determine installed version for {product}')
sys.exit(2)
print(f'Detected version: {".".join(map(str, version))} ({product})')
if cmp_ver(version, safe) < 0:
print(f'VULNERABLE: version is older than fixed baseline {".".join(map(str, safe))}')
sys.exit(1)
else:
print(f'PATCHED: version meets or exceeds fixed baseline {".".join(map(str, safe))}')
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
Sources
- Chrome Releases: Stable Channel Update for Desktop (2026-06-02)
- Chromium issue 506375731
- Chrome Security Page
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS API documentation
- FIRST EPSS model overview
- Canadian Centre for Cyber Security advisory AV26-544
- Chrome Releases: Early Stable Update for Desktop (149.0.7827.53/.54)
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.