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

Use after free in Compositing in Google Chrome prior to 149

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

This is a burglar getting into the lobby, not the vault

CVE-2026-11125 is a CWE-416 use-after-free in Chrome's Compositing pipeline affecting Google Chrome before 149.0.7827.53 on Linux and 149.0.7827.53/54 on Windows and macOS. The trigger is a crafted HTML page, so the attacker can deliver it over the web with no auth, but successful code execution lands inside the renderer sandbox rather than as native code on the host.

The vendor/CISA-ADP 8.8 HIGH score is directionally understandable for *network-reachable memory corruption*, but it overstates enterprise impact because the most important real-world fact is right in the description: execution is inside a sandbox. That means this is usually a first-stage browser foothold that still needs user interaction and often a second bug for host compromise, so for patch-priority purposes this behaves more like a solid MEDIUM than an emergency-wide endpoint crisis.

"Real renderer compromise, but the sandbox wall and click-to-browse requirement keep this out of the fire-drill lane."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Deliver a malicious page

The attacker hosts or injects a crafted HTML page designed to exercise the vulnerable Compositing path. There is no authentication barrier here; delivery can happen through phishing, malvertising, SEO poisoning, or any site the victim browses. No public weaponized exploit repo was located, so assume custom attacker tooling rather than commodity kits right now.
Conditions required:
  • Target uses Chrome below 149.0.7827.53
  • Target browses to attacker-controlled or attacker-influenced content
  • Relevant Compositing code path is reachable from page content
Where this breaks in practice:
  • Requires user interaction (UI:R) rather than passive network reachability
  • Enterprise web filtering, Safe Browsing, and isolation controls reduce malicious-page delivery
  • No public PoC located, so exploit development cost is non-zero
Detection/coverage: Traditional vuln scanners do poorly here; version inventory from EDR/UEM/package management is the practical detector. Secure web gateways and browser telemetry may show suspicious destination patterns, but not the bug trigger itself.
STEP 02

Trigger renderer memory corruption

A crafted page manipulates the vulnerable Compositing lifecycle until freed memory is reused, yielding control of execution in the renderer path. This is a classic browser memory-corruption primitive: technically dangerous, but reliability still depends on allocator behavior, platform hardening, and exploit craftsmanship.
Conditions required:
  • Exploit must bypass normal crash conditions and gain a stable primitive
  • The vulnerable build must not already include the June 2026 fix
Where this breaks in practice:
  • Modern browser mitigations make reliability harder than the CVSS vector suggests
  • A large share of attempts will crash the tab or renderer before giving useful code exec
  • Chrome updates quickly in managed estates, shrinking dwell time for exploitable versions
Detection/coverage: EDR may see repeated browser crashes or anomalous child-process behavior, but signature coverage for a fresh browser UAF is usually weak before public exploit tooling appears.
STEP 03

Operate inside the sandbox

Successful code execution is constrained to a sandboxed renderer process, consistent with Chromium's multi-process design and sandbox model. That sharply limits direct filesystem, device, and OS access, so the attacker typically gets page-context abuse, same-origin data access, and a beachhead for a follow-on escape rather than immediate host takeover.
Conditions required:
  • Renderer compromise succeeds
  • Chrome sandbox remains enabled and functioning normally
Where this breaks in practice:
  • The sandbox is the decisive downward pressure on severity
  • Most enterprises run standard Chrome sandboxing; disabling it is rare and obvious
  • Impact is often contained to browser/session context without a second exploit
Detection/coverage: Behavioral detections may catch token theft attempts, suspicious browser IPC abuse, or follow-on escape activity. Pure renderer-only compromise is difficult to prove retrospectively unless it crashes or chains into something noisier.
STEP 04

Chain for host compromise

To turn this into full endpoint compromise, the attacker usually needs a second vulnerability or misconfiguration that breaks out of the renderer sandbox. That chaining requirement is what separates this from the truly urgent Chrome zero-days that already deliver sandbox escape or confirmed in-the-wild takeover.
Conditions required:
  • Attacker has or can buy/develop a sandbox escape
  • Endpoint defenses do not block or detect the second-stage activity
Where this breaks in practice:
  • Requires an additional exploit stage with its own reliability and cost
  • EDR, exploit protection, and OS hardening have another chance to break the chain
  • No evidence provided that CVE-2026-11125 is being chained in the wild
Detection/coverage: If the chain progresses beyond the renderer, detection odds improve materially: child processes, persistence, token access, LOLBin execution, or sandbox-policy violations become visible to EDR.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo confirmed exploitation found in the sources reviewed. It is not in CISA KEV as of 2026-06-06; see the KEV catalog.
Proof-of-concept availabilityNo public PoC or GitHub exploit repo was located in the reviewed sources. The Chromium issue exists at issues.chromium.org/501517520 but details are restricted, which is normal for fresh Chrome bugs.
EPSSUser-provided EPSS is 0.0008 (~0.08% probability over 30 days). FIRST describes EPSS as a short-term exploitation-likelihood model at first.org/epss and data_stats.
KEV status and datesNot KEV-listed. No CISA date added or due date applies because the CVE does not appear in the Known Exploited Vulnerabilities Catalog.
CVSS vector reality checkCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H from CISA-ADP maps to easy delivery and no auth, but the vendor text says execution is inside a sandbox. That is the missing real-world limiter that makes the base score feel hotter than the operational patch priority.
Affected versionsNVD lists Google Chrome versions before 149.0.7827.53; the Chrome release notes specify 149.0.7827.53 for Linux and 149.0.7827.53/54 for Windows/Mac in the stable desktop advisory.
Fixed versionsFix is in Chrome 149.0.7827.53 (Linux) and 149.0.7827.53/54 (Windows/Mac) per Google's stable channel update. I did not find an authoritative vendor note showing an Extended Stable backport for this specific CVE.
Scanning and exposure dataThis is a client-side browser flaw, not an internet-facing service signature. Shodan/Censys/FOFA/GreyNoise-style telemetry is therefore low-value for direct exposure counting; your real exposure metric is managed endpoint version inventory, browser channel usage, and update lag.
Disclosure timelineChrome/NVD publication is 2026-06-04; NVD shows the record received from Chrome on 2026-06-04 and analyzed on 2026-06-05 at NVD. The fixing stable release was posted on 2026-06-02 in the Chrome advisory.
Reporter / researcherGoogle's release note credits this bug as reported by Google on 2026-04-10, not by an external researcher; see the stable channel advisory entry for CVE-2026-11125.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (6.4/10)

The single biggest downgrade factor is that successful code execution is explicitly confined to the Chrome sandbox, which materially reduces immediate host-compromise blast radius. Add the required user interaction and the absence of KEV or public exploit pressure, and this stops looking like a fleet-wide panic patch despite the scary memory-corruption label.

HIGH Affected/fixed version boundary
HIGH Sandboxed impact materially lowers host-level risk
MEDIUM Current absence of public PoC / in-the-wild exploitation evidence

Why this verdict

  • Downgrade for sandbox confinement: the advisory says code execution is *inside a sandbox*, which cuts the immediate outcome from host takeover to renderer compromise unless the attacker can chain another bug.
  • Downgrade for user interaction: UI:R means this is not wormable and not passively reachable like an exposed appliance bug; it needs the victim to hit attacker-controlled content.
  • Downgrade for lack of field pressure: no KEV listing, no public PoC found, and a very low EPSS all push this out of the emergency lane.
  • Upgrade from LOW because Chrome is everywhere: browser bugs hit a massive installed base, and a renderer foothold can still expose session data and become the first leg of a chain.
  • Upgrade from LOW because this is real memory corruption: use-after-free in a reachable browser component is not cosmetic; it is exploitable in principle and belongs in your normal browser patch program, not in backlog purgatory.

Why not higher?

Because the bug does not by itself deliver unsandboxed endpoint code execution in the available evidence. The attacker needs a user to browse malicious content and then usually needs a second stage to escape the renderer, which compounds friction fast in real enterprises.

Why not lower?

Because Chrome is one of the widest client-side attack surfaces you run, and a renderer compromise is still operationally meaningful. Even inside the sandbox, a browser foothold can target active sessions, web data, and chained exploitation opportunities, so treating it as mere hygiene would undershoot the risk.

05 · Compensating Control

What to do — in priority order.

  1. Enforce browser version compliance — Use UEM/EDR/package management to flag and quarantine endpoints below 149.0.7827.53 where feasible. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but in practice browser drift should be corrected much faster because version inventory is easy.
  2. Block unmanaged Chrome channels — Restrict portable, user-installed, or unmanaged Chrome variants that can evade enterprise update policy. Do this during the normal remediation cycle so patched builds actually land before the remediation deadline.
  3. Harden risky browsing paths — Apply Safe Browsing, secure web gateway filtering, attachment detonation, and browser isolation for high-risk user groups. These controls reduce malicious-page delivery while you work through standard browser remediation; for MEDIUM, there is no separate noisgate mitigation clock.
  4. Watch for crash clusters — Hunt for spikes in Chrome tab crashes, renderer restarts, and suspicious browsing destinations around high-value users. This is not a perfect detector, but it is the best practical early-warning signal for exploit development against fresh browser memory bugs.
What doesn't work
  • Relying on perimeter vuln scanning doesn't help much because this is a client-side browser issue, not an exposed server socket.
  • MFA does nothing against the memory-corruption step itself; it only helps downstream account abuse if sessions are stolen.
  • Generic WAF rules are largely irrelevant because the exploit lands in browser-side page processing, not your web server.
  • Assuming the sandbox makes patching optional is wrong; the sandbox lowers severity, but it does not erase the risk of renderer compromise or chaining.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your remote execution/UEM agent. Invoke it with python3 check_chrome_cve_2026_11125.py on macOS/Linux or py check_chrome_cve_2026_11125.py on Windows; no admin rights are required unless your tooling blocks reading standard install paths.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_chrome_cve_2026_11125.py
# Determine whether the local Google Chrome install is vulnerable to CVE-2026-11125.
# Outputs exactly one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import re
import subprocess
import sys
from shutil import which

TARGET = (149, 0, 7827, 53)


def parse_version(text):
    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_version(a, b):
    return (a > b) - (a < b)


def run_cmd(cmd):
    try:
        p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=10)
        out = (p.stdout or '') + '\n' + (p.stderr or '')
        return out.strip()
    except Exception:
        return ''


def get_version_linux():
    candidates = [
        'google-chrome',
        'google-chrome-stable',
        'google-chrome-beta',
        'google-chrome-unstable',
        'chromium-browser',
        'chromium',
    ]
    for c in candidates:
        path = which(c)
        if path:
            out = run_cmd([path, '--version'])
            v = parse_version(out)
            if v:
                return v, path
    return None, None


def get_version_macos():
    app_paths = [
        '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
        os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
        '/Applications/Google Chrome Beta.app/Contents/MacOS/Google Chrome Beta',
        '/Applications/Google Chrome Dev.app/Contents/MacOS/Google Chrome Dev',
        '/Applications/Chromium.app/Contents/MacOS/Chromium',
    ]
    for path in app_paths:
        if os.path.exists(path):
            out = run_cmd([path, '--version'])
            v = parse_version(out)
            if v:
                return v, path
    return None, None


def get_version_windows():
    paths = [
        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'),
        os.path.join(os.environ.get('ProgramFiles', r'C:\Program Files'), 'Chromium', 'Application', 'chrome.exe'),
    ]
    for path in paths:
        if path and os.path.exists(path):
            out = run_cmd([path, '--version'])
            v = parse_version(out)
            if v:
                return v, path
    return None, None


def main():
    system = platform.system().lower()
    version = None
    source = None

    if 'linux' in system:
        version, source = get_version_linux()
    elif 'darwin' in system:
        version, source = get_version_macos()
    elif 'windows' in system:
        version, source = get_version_windows()
    else:
        print('UNKNOWN')
        sys.exit(2)

    if not version:
        print('UNKNOWN')
        sys.exit(2)

    # Chrome advisory says fixed at 149.0.7827.53 (Linux) and 149.0.7827.53/54 (Windows/Mac).
    # Treat any build >= 149.0.7827.53 as patched for this CVE.
    if cmp_version(version, TARGET) >= 0:
        print('PATCHED')
        sys.exit(0)
    else:
        print('VULNERABLE')
        sys.exit(1)


if __name__ == '__main__':
    main()
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, do not treat this like a zero-day fire drill, but do fold it into your browser compliance push immediately: pull a version inventory for all Chrome installs, identify anything below 149.0.7827.53, and clean up unmanaged browser installs first because they are where drift hides. For a MEDIUM verdict there is no noisgate mitigation SLA — go straight to the 365-day remediation window; your noisgate remediation SLA is <= 365 days, though any mature enterprise should finish browser-version cleanup far sooner than that because the operational cost is low and the exposure surface is broad.

Sources

  1. NVD CVE-2026-11125
  2. Google Chrome Stable Channel Update for Desktop (June 2026)
  3. Chromium issue 501517520
  4. Chromium Multi-process Architecture
  5. Chromium GPU Accelerated Compositing in Chrome
  6. CISA Known Exploited Vulnerabilities Catalog
  7. FIRST EPSS overview
  8. FIRST EPSS data statistics
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.