This is a second lock behind a first broken door, not a front-door smash
CVE-2026-11120 is an improper input validation bug in Chrome's Enterprise Reporting component. Google says versions before 149.0.7827.53 are affected, with desktop fixes shipped in 149.0.7827.53 for Linux and 149.0.7827.53/54 for Windows and macOS. The important buried detail is the prerequisite: the attacker must already have compromised the renderer process and then use a crafted HTML page to try to turn that foothold into a sandbox escape.
The vendor-style 9.6 CRITICAL score overstates standalone enterprise risk because it prices the bug as if the attacker can go straight from web content to full compromise. In reality this is a stage-two browser exploit that usually needs a separate renderer RCE/UXSS bug, plus user browsing, plus exploit reliability across Chrome's hardening. That's still serious because Chrome is everywhere and sandbox escapes are valuable in exploit chains, but for patch scheduling this is closer to a chain amplifier than an urgent single-bug crisis.
4 steps from start to impact.
Land the victim on attacker-controlled web content
- Victim uses vulnerable Chrome before
149.0.7827.53/54 - Victim visits attacker-controlled content
- Attacker has a separate renderer-compromise primitive
- User interaction is required
- Safe Browsing, URL filtering, and mail/web isolation cut down delivery success
- This CVE is not the initial code-exec primitive
Compromise the renderer with a companion bug
- A working renderer exploit for the target Chrome build
- Exploit reliability against the victim OS and browser channel
- Requires a second vulnerability or exploit technique
- Browser exploit reliability is fragile across minor versions
- Modern browser hardening raises development cost
Use Enterprise Reporting validation flaw to attempt sandbox escape
- Renderer already compromised
- Target remains on a vulnerable Chrome build
- Reachable Enterprise Reporting code path
- Exploit chain now depends on a component-specific escape
- No public exploitation evidence or KEV listing
- Unknown reliability outside lab conditions
chrome child process activity, and EDR detections after sandbox exit are the most realistic signals.Execute post-escape payload on the endpoint
- Successful sandbox escape
- Ability to run follow-on payloads under the user's context
- EDR, application control, and browser child-process restrictions can catch the breakout
- User-context execution still may not equal admin rights
- Post-exploitation noise is far easier to detect than the web trigger
chrome.exe/Chrome, unusual module loads, file drops in user space, and browser-driven credential access.The supporting signals.
| In-the-wild status | No public evidence of active exploitation surfaced in the reviewed sources, and the CVE is not KEV-listed. |
|---|---|
| Proof-of-concept availability | No public PoC or GitHub exploit for CVE-2026-11120 was found in primary-source review; expect any real weaponization to live inside a private multi-bug chain. |
| EPSS | 0.00047 from the supplied intel — extremely low relative likelihood of observed exploitation over 30 days. |
| KEV status | Not listed in the CISA KEV catalog as of this assessment. |
| Vendor vs reality | Prompt supplied a vendor baseline of CRITICAL 9.6 with AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H, but Google's own Chrome release notes label the bug Medium and the description itself says the attacker must have already compromised the renderer. |
| Affected versions | Chrome prior to 149.0.7827.53; Google separately states fixed desktop builds are 149.0.7827.53 on Linux and 149.0.7827.53/54 on Windows/macOS. |
| Fixed versions | Patch to at least 149.0.7827.53 everywhere; for Windows/macOS, 149.0.7827.54 is also part of the fixed rollout. |
| Exposure population | Chrome is ubiquitous, which keeps the floor above LOW. But this bug is a post-renderer-compromise sandbox escape, so the truly exposed population is much smaller than raw browser install count suggests. |
| Scanning / exposure data | Internet scanners like Shodan/Censys/FOFA are a bad fit for a client browser issue. Your source of truth is endpoint inventory, EDR, MDM/UEM, or Chrome enterprise reporting rather than external exposure scans. |
| Disclosure / reporting | The CVE record was published on 2026-06-04; Google says it was reported by Google on 2026-04-10 in the stable channel advisory. |
noisgate verdict.
The decisive factor is the hidden prerequisite: this is not an unauthenticated internet-to-endpoint bug by itself, but a sandbox escape that assumes prior renderer compromise. That turns a scary CVSS outcome into a much narrower real-world attack population, despite Chrome's huge install base.
Why this verdict
- Major downgrade for attacker position: the attack path is not true
AV:N/PR:Nin practice because the vendor description itself requires a pre-compromised renderer. That implies the operator already solved initial browser compromise with a separate bug, which is strong downward pressure from the9.6baseline. - Another downgrade for reachable population: while Chrome is everywhere, only the subset of users on vulnerable builds who can be driven to a malicious page and hit a working renderer exploit chain are realistically reachable. That is far smaller than 'all Chrome users on the internet.'
- No threat acceleration signals: no KEV listing, no public exploitation evidence, and a very low supplied EPSS (
0.00047) all argue against emergency treatment. This is a valuable chain component, not a field-proven mass-burn issue.
Why not higher?
I am not keeping this at HIGH or CRITICAL because the exploit chain starts with a prerequisite that most vendor CVSS readers miss: the attacker must already own the renderer. That means this CVE is post-initial-compromise inside the browser security model, not a one-bug drive-by full compromise. With no KEV listing or public exploitation evidence, the urgency simply does not support a top-tier bucket.
Why not lower?
I am not pushing this to LOW or IGNORE because Chrome is a massive enterprise attack surface and sandbox escapes matter. If an operator has or buys the companion renderer bug, this kind of flaw can turn a sandboxed browser foothold into endpoint impact quickly. For organizations managing large fleets, that keeps it above mere backlog trivia.
What to do — in priority order.
- Enforce Chrome auto-update compliance — Make browser-version compliance visible in UEM/EDR and force lagging endpoints onto fixed builds. For a MEDIUM verdict there is no mitigation SLA, but this is still the cleanest control while you work inside the 365-day remediation window.
- Prioritize companion renderer bugs above this CVE — If you are triaging multiple Chrome CVEs from the same release, patch memory-corruption and renderer-RCE candidates first because they are the missing first half of the chain. Do this immediately in your browser patch wave planning even though this specific CVE does not carry its own mitigation deadline.
- Tighten browser exploit guardrails — Keep Safe Browsing, web filtering, exploit protection, and EDR browser child-process rules enabled to make the initial renderer-compromise stage harder and the post-escape stage noisier. These are sensible compensations now, especially for outlier devices that cannot take the update promptly.
- Use managed-browser inventory as source of truth — Track vulnerable Chrome versions through MDM/UEM, EDR software inventory, or Chrome enterprise management rather than perimeter scans. That lets you close exceptions methodically during the normal remediation cycle.
- Perimeter vulnerability scanning doesn't help much; this is a client browser flaw, not an exposed server daemon.
- A WAF is irrelevant because the vulnerable code runs on the endpoint inside Chrome, not behind your web applications.
- Relying on CVSS alone will over-prioritize this item; the real-world exploit path is much narrower than the
9.6label suggests.
Crowdsourced verification payload.
Run this on the target endpoint or through your fleet tooling. Invoke it with python3 chrome_cve_2026_11120_check.py on macOS/Linux or py chrome_cve_2026_11120_check.py on Windows; no admin rights are usually needed, though registry access on locked-down Windows images may benefit from standard local read access.
#!/usr/bin/env python3
# CVE-2026-11120 Chrome version check
# Outputs: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import subprocess
import sys
THRESHOLD = (149, 0, 7827, 53)
def parse_version(text):
if not text:
return None
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 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 windows_versions():
versions = []
candidates = [
r'C:\Program Files\Google\Chrome\Application\chrome.exe',
r'C:\Program Files (x86)\Google\Chrome\Application\chrome.exe',
os.path.expandvars(r'%LOCALAPPDATA%\Google\Chrome\Application\chrome.exe'),
]
for path in candidates:
if path and os.path.exists(path):
out = run_cmd([
'powershell', '-NoProfile', '-Command',
f"(Get-Item '{path}').VersionInfo.ProductVersion"
])
v = parse_version(out)
if v:
versions.append((path, v))
reg_paths = [
r'HKLM\Software\Google\Chrome\BLBeacon',
r'HKLM\Software\WOW6432Node\Google\Chrome\BLBeacon',
r'HKCU\Software\Google\Chrome\BLBeacon',
]
for key in reg_paths:
out = run_cmd(['reg', 'query', key, '/v', 'version'])
v = parse_version(out)
if v:
versions.append((key, v))
return versions
def mac_versions():
versions = []
candidates = [
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
]
for path in candidates:
if os.path.exists(path):
out = run_cmd([path, '--version'])
v = parse_version(out)
if v:
versions.append((path, v))
plist = '/Applications/Google Chrome.app/Contents/Info.plist'
if os.path.exists(plist):
out = run_cmd(['/usr/bin/defaults', 'read', plist.replace('/Info.plist', ''), 'CFBundleShortVersionString'])
v = parse_version(out)
if v:
versions.append((plist, v))
return versions
def linux_versions():
versions = []
candidates = [
'google-chrome',
'google-chrome-stable',
'/usr/bin/google-chrome',
'/usr/bin/google-chrome-stable',
'chromium',
'chromium-browser',
]
seen = set()
for cmd in candidates:
if cmd in seen:
continue
seen.add(cmd)
out = run_cmd([cmd, '--version'])
v = parse_version(out)
if v:
versions.append((cmd, v))
return versions
def main():
system = platform.system().lower()
found = []
if 'windows' in system:
found = windows_versions()
elif 'darwin' in system:
found = mac_versions()
else:
found = linux_versions()
if not found:
print('UNKNOWN: Google Chrome not found or version unreadable')
sys.exit(2)
# Deduplicate by version string while preserving evidence
unique = []
seen = set()
for source, ver in found:
key = (source, ver)
if key not in seen:
unique.append((source, ver))
seen.add(key)
vulnerable = []
patched = []
for source, ver in unique:
if cmp_ver(ver, THRESHOLD) < 0:
vulnerable.append((source, ver))
else:
patched.append((source, ver))
if vulnerable:
detail = '; '.join([f'{src}={".".join(map(str, ver))}' for src, ver in vulnerable])
print(f'VULNERABLE: {detail}')
sys.exit(1)
else:
detail = '; '.join([f'{src}={".".join(map(str, ver))}' for src, ver in patched])
print(f'PATCHED: {detail}')
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
149.0.7827.53/54, confirm auto-update is working, and roll stragglers into the next normal browser update wave; there is no noisgate mitigation SLA — go straight to the 365-day remediation window. In practice, because browser updates are low-friction and this bug is a chain component, most mature teams should still clear it well before the noisgate remediation SLA limit of 365 days, while giving higher urgency to any accompanying Chrome renderer/RCE bugs from the same release.Sources
- Google Chrome stable channel advisory
- Chromium issue 501467566
- CIRCL Vulnerability-Lookup entry for CVE-2026-11120
- Canadian Centre for Cyber Security advisory AV26-544
- Chrome Enterprise help: enable browser cloud reporting
- Chrome Enterprise policy: CloudProfileReportingEnabled
- CISA Known Exploited Vulnerabilities Catalog
- SecurityWeek coverage of Chrome 149 fixes
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.