← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-10956 · CWE-416 · Disclosed 2026-06-04

Use after free in MimeHandlerView in Google Chrome prior to 149

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

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.

"Renderer code exec is serious, but this is still a sandboxed stage-1 browser bug with no exploit evidence."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Deliver crafted web content to Chrome

The attacker hosts or embeds malicious content that exercises 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.
Conditions required:
  • 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 MimeHandlerView is actually reached
Where this breaks in practice:
  • 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
Detection/coverage: Standard vuln scanners can flag outdated Chrome versions, but they do not validate exploitability of the MimeHandlerView path. Web proxies, browser telemetry, and EDR may catch suspicious delivery or crash spikes, but coverage is indirect.
STEP 02

Trigger the use-after-free

The malicious content coerces Chrome into freeing an object and later dereferencing it. To weaponize this, the attacker needs a reliable heap layout and a browser-state sequence that survives modern mitigations. This is where exploit engineering cost lives.
Conditions required:
  • A working exploit primitive for this exact Chrome build family
  • Heap grooming or timing that is stable enough for the target platform
Where this breaks in practice:
  • 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
Detection/coverage: Crash telemetry, repeated renderer terminations, and EDR child-process anomalies may surface exploit attempts. Signature-based network detection is weak unless a public PoC emerges.
STEP 03

Gain code execution in the renderer sandbox

If the memory corruption is controlled, the attacker gets code execution inside Chrome's sandboxed process, not arbitrary native execution on the host. That is meaningful for session theft, in-browser actions, and staging, but it is not the same as owning the endpoint.
Conditions required:
  • Exploit reliability sufficient to avoid simple denial-of-service behavior
  • The target's browser hardening features do not break the exploit chain
Where this breaks in practice:
  • 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
Detection/coverage: Behavioral EDR can sometimes spot shellcode-like activity, suspicious browser child processes, or post-exploitation staging. Browser isolation products materially reduce impact at this stage.
STEP 04

Chain to real endpoint impact

To turn this into a full enterprise incident, the attacker usually needs a sandbox escape, token abuse opportunity, or a user-session objective reachable from inside the compromised browser context. Without that second stage, the blast radius is materially constrained compared with a true remote host takeover bug.
Conditions required:
  • A second vulnerability, misconfiguration, or in-browser objective worth stealing
  • Access to an interesting user session, SaaS token, or sensitive app workflow
Where this breaks in practice:
  • 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
Detection/coverage: This is where defenders have the best shot: identity telemetry, EDR, CASB, and browser-session monitoring can all surface abnormal follow-on behavior.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo 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 statusNot 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 availabilityNo 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.
EPSS0.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 meaningCVSS: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 versionsChrome 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 versionsUpgrade 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 realityInternet 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 reportingDisclosed 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 radiusChrome 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.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (6.2/10)

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.

HIGH Affected version range and vendor fix versions
HIGH No KEV listing as of 2026-06-05
MEDIUM Reassessment that this should be MEDIUM rather than vendor HIGH
LOW Exact exploit path through `MimeHandlerView` because Google has restricted bug detail

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 MimeHandlerView path 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.

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
What doesn't work
  • 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 MimeHandlerView path 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.
06 · Verification

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.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/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()
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, treat this as a broad but not emergency browser hygiene item: pull an endpoint inventory for Chrome versions, confirm where auto-update is failing, and close exceptions in kiosks, VDI images, and deferred-update rings first. Because this reassessment is MEDIUM and there is no active exploitation evidence, there is no noisgate mitigation SLA — go straight to the 365-day remediation window; the noisgate remediation SLA is therefore ≤365 days to get vulnerable Chrome builds upgraded, with earlier cleanup for high-risk user groups and unmanaged fleets where version lag is common.

Sources

  1. Chrome Releases: Stable Channel Update for Desktop (2026-06-02)
  2. Chromium issue 506375731
  3. Chrome Security Page
  4. CISA Known Exploited Vulnerabilities Catalog
  5. FIRST EPSS API documentation
  6. FIRST EPSS model overview
  7. Canadian Centre for Cyber Security advisory AV26-544
  8. Chrome Releases: Early Stable Update for Desktop (149.0.7827.53/.54)
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.