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.
4 steps from start to impact.
Deliver a malicious page
- 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
- 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
Trigger renderer memory corruption
- Exploit must bypass normal crash conditions and gain a stable primitive
- The vulnerable build must not already include the June 2026 fix
- 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
Operate inside the sandbox
- Renderer compromise succeeds
- Chrome sandbox remains enabled and functioning normally
- 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
Chain for host compromise
- Attacker has or can buy/develop a sandbox escape
- Endpoint defenses do not block or detect the second-stage activity
- 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
The supporting signals.
| In-the-wild status | No 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 availability | No 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. |
| EPSS | User-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 dates | Not 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 check | CVSS: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 versions | NVD 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 versions | Fix 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 data | This 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 timeline | Chrome/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 / researcher | Google'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. |
noisgate verdict.
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.
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:Rmeans 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.
What to do — in priority order.
- Enforce browser version compliance — Use UEM/EDR/package management to flag and quarantine endpoints below
149.0.7827.53where 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. - 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.
- 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.
- 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.
- 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.
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.
#!/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()
If you remember one thing.
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
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.