Like slipping a pick into the lobby, but still needing another key for the server room
CVE-2026-11230 is a use-after-free in Chrome's Extensions code affecting Google Chrome before 149.0.7827.53. A victim has to load attacker-controlled HTML, after which the attacker can gain arbitrary code execution inside Chrome's sandbox, not native code execution on the host outside the browser boundary. Based on the available public description, this is a client-side memory corruption issue with broad endpoint reach because Chrome is everywhere, but the affected range is straightforward: anything older than 149.0.7827.53.
The vendor/NVD-style 8.8 HIGH score is technically defensible if you grade only the bug primitive, but it overstates enterprise host risk. The decisive friction is the same one Google hints at with its own lower component severity: the code runs inside the sandbox. That means this is usually step one of a chain, not the full chain. No KEV entry, no public exploitation evidence, and a very low EPSS all push this down from emergency patch territory to routine-but-real browser patching.
4 steps from start to impact.
Land the victim on attacker HTML
- Target uses Google Chrome older than
149.0.7827.53 - Target visits attacker-controlled or attacker-influenced content
- Exploit path is reachable from normal web content
- User interaction is mandatory
- Email security, URL filtering, safe browsing, and ad blocking cut down delivery volume
- Browsers auto-update quickly in many enterprises
Trigger the use-after-free in Extensions
- Target build is vulnerable
- Attacker has a reliable trigger for the bug
- Chrome mitigations do not prevent exploitation in that build
- Memory corruption reliability varies across builds, hardware, and mitigations
- No public exploit tooling is visible from the currently available sources
- Crash-only behavior is common before a stable exploit exists
Operate inside the sandbox
- Exploit succeeds past renderer/browser mitigations
- Attacker objective can be achieved from sandboxed execution
- Sandboxing sharply limits direct OS impact
- Privilege escalation or sandbox escape would usually be needed for endpoint takeover
- Enterprise session protections and re-auth controls reduce some post-exploit value
Chain a second bug for full endpoint compromise
- Attacker has a second exploit or a useful local post-exploitation path
- The host lacks controls that catch the follow-on stage
- Requires additional exploit material beyond this CVE
- EDR, application control, and OS exploit mitigations often stop the second stage
- This is now post-browser foothold, not single-bug RCE
The supporting signals.
| In-the-wild status | No public evidence of active exploitation found in the reviewed sources, and not listed in CISA KEV as of the current catalog view (CISA KEV) |
|---|---|
| Proof-of-concept availability | No public PoC identified from the reviewed sources; SynScan explicitly shows no exploit information and the Chromium bug details remain restricted (SynScan, Chromium issue) |
| EPSS | 0.0008 per the user-provided intel, which is directionally consistent with very low near-term exploitation probability under the FIRST EPSS model (FIRST EPSS, API docs) |
| KEV status | Not KEV-listed; no CISA due date exists because it is not in the catalog (CISA KEV) |
| CVSS vector readout | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H means remote, no auth, user interaction required. The score assumes high impact after code execution, but the public description says that execution is inside a sandbox, which materially lowers real endpoint risk. |
| Affected versions | Chrome prior to 149.0.7827.53; the public description does not currently provide a more granular platform split for this CVE (CVE record reference via SynScan) |
| Fixed versions | Update to 149.0.7827.53 or later. Google also published an early stable desktop release 149.0.7827.53/.54 for Windows and Mac before broader rollout (Early Stable update) |
| Exposure / scanning reality | This is a client-side browser bug, so Shodan/Censys/FOFA-style internet exposure counts are not meaningful. The real exposure metric is managed Chrome install base, not externally reachable services. |
| Disclosure date | 2026-06-04 per the provided intel and mirrored third-party CVE aggregators (VulDB mirror, SynScan) |
| Researcher / reporting org | The reviewed public sources do not name an external reporter for this exact CVE. The Chromium issue exists, but details are restricted, so attribution is currently unknown from public sources (Chromium issue) |
noisgate verdict.
The single biggest downgrade factor is sandboxed-only code execution. This bug can hand an attacker a browser foothold, but without a second-stage escape it usually stops short of the host-level impact that enterprise teams should reserve HIGH for.
Why this verdict
- Downgrade: sandbox boundary matters — the public description says code execution is *inside a sandbox*, which means this is usually a browser foothold rather than full workstation compromise.
- Downgrade: no live-fire evidence — no KEV listing, no public exploitation evidence, and a user-provided EPSS of
0.0008all argue against emergency prioritization. - Downgrade: exploit delivery needs a human —
UI:Rmeans the attacker still needs page view traffic, which modern email/web controls suppress at scale. - Offsetting upward pressure: Chrome is ubiquitous — because Chrome is widely deployed, even a sandboxed browser bug can still produce meaningful identity/session risk across a large fleet.
Why not higher?
A higher rating would require either evidence of exploitation, a public reliable exploit, or impact outside the sandbox. We do not have that here. As currently described, this is not a one-bug domain-wide disaster; it is a client-side exploit primitive that still needs additional help to become an endpoint takeover.
Why not lower?
This is still remote, unauthenticated, and broadly reachable through normal browsing. Even sandboxed execution can expose sensitive in-browser data, sessions, and application activity. On a 10,000-host fleet, you do not ignore browser memory corruption just because it stops at the sandbox.
What to do — in priority order.
- Force browser auto-update compliance — Verify policy enforcement so Chrome cannot lag behind the fixed build. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but for browsers you should still use your normal rapid update ring instead of letting drift accumulate.
- Tighten web filtering on untrusted categories — Reduce exposure to exploit delivery by blocking newly registered domains, known-malvertising sources, and uncategorized destinations. This is a useful risk reducer while patch rollout completes, even though there is no noisgate mitigation deadline for MEDIUM.
- Restrict extension sprawl — Use enterprise allowlisting and remove unnecessary extensions. The flaw sits in the Extensions area, and while the public details are sparse, reducing extension surface is sensible hardening during the remediation window.
- Watch for browser crash anomalies — Sudden Chrome crash clusters after exposure to the same sites can be an early sign of exploit development or failed attempts. Feed crash telemetry, proxy logs, and EDR browser events into hunting while you patch.
- A network IPS signature is not a dependable control here because client-side memory corruption is usually exploit-shape dependent and easy to morph.
- MFA does not prevent exploitation of the browser bug itself; it only reduces some downstream session-abuse value.
- Vulnerability scanners aimed at servers will not meaningfully measure exposure because this is a local browser version problem, not an internet-facing service fingerprint.
Crowdsourced verification payload.
Run this on the target endpoint or through your software-distribution/remote-exec tooling. Invoke it with python3 chrome_cve_2026_11230_check.py; it needs only normal user rights because it reads local Chrome version information and compares it to the fixed build 149.0.7827.53.
#!/usr/bin/env python3
# Check Google Chrome version for CVE-2026-11230
# Outputs: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import shutil
import subprocess
import sys
FIXED = (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 version_str(v):
return '.'.join(str(x) for x in v)
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 get_windows_version():
candidates = [
["reg", "query", r"HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe", "/ve"],
["reg", "query", r"HKLM\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe", "/ve"],
]
exe_path = None
for cmd in candidates:
try:
p = subprocess.run(cmd, capture_output=True, text=True, timeout=10)
data = (p.stdout or '') + (p.stderr or '')
m = re.search(r'REG_SZ\s+(.*chrome\.exe)', data, re.IGNORECASE)
if m:
exe_path = m.group(1).strip()
break
except Exception:
pass
common_paths = [
exe_path,
r"C:\Program Files\Google\Chrome\Application\chrome.exe",
r"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe",
]
for path in common_paths:
if path and os.path.exists(path):
v = get_version_from_command([path, "--version"])
if v:
return v
return None
def get_macos_version():
path = "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"
if os.path.exists(path):
return get_version_from_command([path, "--version"])
return None
def get_linux_version():
for binary in ["google-chrome", "google-chrome-stable", "chromium", "chromium-browser"]:
full = shutil.which(binary)
if full:
v = get_version_from_command([full, "--version"])
if v:
return v
return None
def main():
system = platform.system().lower()
version = None
if 'windows' in system:
version = get_windows_version()
elif 'darwin' in system:
version = get_macos_version()
elif 'linux' in system:
version = get_linux_version()
if version is None:
print("UNKNOWN: Could not determine Chrome version on this host")
sys.exit(2)
if version < FIXED:
print(f"VULNERABLE: Detected Chrome {version_str(version)} < {version_str(FIXED)}")
sys.exit(1)
else:
print(f"PATCHED: Detected Chrome {version_str(version)} >= {version_str(FIXED)}")
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
149.0.7827.53 or newer through your normal browser ring now, verify update policy compliance this week, and complete fleet remediation within the noisgate remediation SLA of ≤365 days. Do not burn emergency change budget unless fresh exploitation evidence appears.Sources
- Google Chrome Releases - Early Stable Update for Desktop
- Google Chrome Releases - Stable Channel Update for Desktop (May 12, 2026)
- Chromium issue tracker reference
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS overview
- FIRST EPSS API documentation
- CWE-416: Use After Free
- SynScan CVE mirror for CVE-2026-11230
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.