This is the deadbolt behind the front door, not the open window
CVE-2026-11146 is an input-validation flaw in Chrome's Chromoting component affecting Google Chrome versions before 149.0.7827.53. The bug can let an attacker who has already compromised the renderer process use a crafted HTML page to potentially escape Chrome's sandbox, turning renderer-level code execution into a host-level foothold.
The published 9.6/CRITICAL score overstates the real enterprise urgency when assessed as a patch queue item. The decisive friction is that this is not initial access and not standalone RCE; it is a second-stage post-renderer compromise bug, and Google itself labeled the Chromium-side bug Medium. That keeps it important, because Chrome is everywhere and sandbox escapes are premium chain components, but it does not deserve top-of-queue treatment absent active exploitation.
4 steps from start to impact.
Land the victim on a malicious page
- User visits attacker-controlled or attacker-influenced HTML content
- Chrome version is older than 149.0.7827.53
- Requires user interaction (
UI:R) - Safe Browsing, email filtering, and content controls can block the lure before the browser is involved
Exploit a separate renderer bug first
- A separate renderer-compromise vulnerability is available and works on the target build
- The victim browses with a compatible exploit environment
- This is the biggest severity reducer: the attacker must already be partway through a successful browser exploit chain
- Modern browser hardening, renderer isolation, exploit mitigations, and crash telemetry increase failure rates
Trigger the Chromoting validation flaw
Chromoting using crafted HTML to attempt a sandbox escape. This is the weaponized step where the bug matters: it is a sandbox-boundary bypass, not first-stage code execution.- Renderer process already under attacker control
- Affected Chromoting code path is reachable on the target build
- Bug details remain restricted in the Chromium issue, slowing broad weaponization
- Successful sandbox escapes are usually brittle, version-sensitive, and harder to operationalize than the CVSS suggests
Break out to user-context code execution
- Sandbox escape succeeds
- Endpoint controls fail to block post-escape behavior
- EDR, application control, user-context restrictions, and post-exploitation telemetry can still stop or expose the operator
- Blast radius is limited to the browsing user's endpoint, not a server-side mass compromise
The supporting signals.
| In-the-wild status | No known active exploitation in reviewed sources. The bug is not in CISA KEV, and OpenCVE surfaces CISA SSVC as Exploitation: none. |
|---|---|
| Proof-of-concept availability | No public PoC surfaced in targeted web/GitHub searches at review time. Chromium issue 501709220 is still access-restricted, which usually slows copycat weaponization. |
| EPSS | 0.00047 from public aggregators sourcing FIRST; that is *very low*. Reviewed sources did not surface a current percentile, so do not over-interpret CVSS here. |
| KEV status | Not KEV-listed as of 2026-06-06 review. No CISA due date exists because it is absent from the catalog. |
| CVSS vector reality check | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H models browser compromise impact well, but it misses the practical prerequisite in the description: the attacker must have already compromised the renderer process. |
| Affected versions | Google Chrome prior to 149.0.7827.53. Chrome release notes state desktop stable moved to 149.0.7827.53 (Linux) and 149.0.7827.53/54 (Windows/Mac). |
| Fixed version | 149.0.7827.53 or later. For managed estates, also watch channel pinning and lagging rollout rings; Chrome's staged release means some fleets trail for days. |
| Vendor vs reality | Mismatch: CISA ADP/NVD shows 9.6 Critical, but the Chrome CNA description explicitly says Chromium security severity: Medium. For defenders, the second-stage prerequisite is the deciding factor, and Google's label is closer to operational reality. |
| Exposure population | Chrome is massively deployed; StatCounter showed roughly 73.26% worldwide desktop browser share for February 2026. *Inference:* internet-wide scanners like Shodan/Censys are the wrong lens because this is a client browser, not an internet-listening service. |
| Researcher / disclosure trail | Reported by Google on 2026-04-11 in the stable release notes list; CVE published 2026-06-04. Bug tracker reference is Chromium issue 501709220. |
noisgate verdict.
The single biggest factor is that this bug requires prior renderer compromise, which means the attacker already owns another exploit stage before CVE-2026-11146 matters. That sharply narrows the reachable population and pushes this out of emergency patch territory even though the end-state impact of a successful chain is serious.
Why this verdict
- Major downgrade: requires a prior renderer compromise — attacker position is effectively *post-exploitation inside the browser*, not unauthenticated remote code execution from scratch.
- Further downgrade: user interaction is still required — the victim must browse to crafted content, so SWG, Safe Browsing, email controls, and user behavior all reduce reach.
- Another downgrade: no exploitation evidence — no KEV listing, no public PoC found, and SSVC enrichment says
Exploitation: none/Automatable: no. - Counterweight upward: Chrome is everywhere — the affected software population is huge, so a viable sandbox escape still matters when paired with another browser bug.
- Counterweight upward: blast radius at the endpoint is real — if chained successfully, this converts renderer code exec into user-context compromise on a workstation.
Why not higher?
Because this CVE does not get the attacker into the box by itself. Requiring internal browser foothold plus a separate exploit stage is compounding friction, and there is no public evidence yet that operators are spending chains on this bug in the wild.
Why not lower?
Because sandbox escapes in Chrome are not hygiene-only bugs. In a product with Chrome's deployment footprint, a reliable chain component can materially raise attacker success once the first-stage renderer bug exists, so this should stay above backlog-only treatment.
What to do — in priority order.
- Unpin lagging Chrome channels — Find OUs, VDI pools, kiosk builds, and gold images pinned below 149.0.7827.53 and remove version pinning that blocks normal browser security uptake. For a MEDIUM noisgate verdict there is no mitigation SLA — go straight to the 365-day remediation window, but do this early because browser version drift is what turns chain bugs into long-tail exposure.
- Verify auto-update actually lands — Do not assume Chrome updated just because policy says it should. Validate managed endpoints are receiving the stable build and restarting into it; for this MEDIUM verdict there is no mitigation SLA, so use the 365-day remediation window to clean up update reliability rather than treating this like a fire drill.
- Harden web delivery controls — Keep Safe Browsing, SWG, email URL defense, and malvertising filtering tuned because they cut off the crafted-page delivery stage before any browser chain executes. There is no mitigation SLA for MEDIUM here, but these controls reduce chain completion while remediation proceeds inside the 365-day window.
- Watch browser child-process and exploit telemetry — Prioritize detections for suspicious browser-launched shells, script engines, LOLBins, and memory abuse from
chrome.exeor Chrome child processes. This does not patch the bug, but it is the most useful runtime control if an attacker tries to turn a renderer exploit into post-sandbox endpoint actions.
- A WAF does not help; this is a client-side browser issue, not a server-side web app flaw you can shield at the perimeter.
- Simple port scanning does not measure exposure; Chrome is not an internet-listening service, so Shodan-style counts tell you almost nothing about your affected population.
- Treating this as a standalone RCE leads to bad prioritization; the real risk comes only when another renderer exploit is already in play.
Crowdsourced verification payload.
Run this on the target endpoint or through your endpoint audit tooling. Invoke it with python3 check_cve_2026_11146.py on macOS/Linux or py check_cve_2026_11146.py on Windows; standard user rights are usually enough because it reads local install metadata and common binary paths.
#!/usr/bin/env python3
# check_cve_2026_11146.py
# Detect whether locally installed Google Chrome is vulnerable to CVE-2026-11146
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import subprocess
import sys
from shutil import which
FIXED_VERSION = (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 compare_versions(a, b):
if a is None or b is None:
return None
return (a > b) - (a < b)
def run_cmd(cmd):
try:
cp = subprocess.run(cmd, capture_output=True, text=True, timeout=10)
out = (cp.stdout or '') + '\n' + (cp.stderr or '')
return out.strip()
except Exception:
return ''
def windows_version():
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"])
ver = parse_version(out)
if ver:
return ver, path
reg_queries = [
[
'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'
],
]
for q in reg_queries:
out = run_cmd(q)
m = re.search(r'REG_SZ\s+(.+chrome\.exe)', out, re.IGNORECASE)
if m:
path = m.group(1).strip()
if os.path.exists(path):
pout = run_cmd(['powershell', '-NoProfile', '-Command', f"(Get-Item '{path}').VersionInfo.ProductVersion"])
ver = parse_version(pout)
if ver:
return ver, path
return None, None
def mac_version():
app = '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'
if os.path.exists(app):
out = run_cmd([app, '--version'])
ver = parse_version(out)
if ver:
return ver, app
return None, None
def linux_version():
binaries = [
'google-chrome',
'google-chrome-stable',
'/opt/google/chrome/google-chrome',
'/usr/bin/google-chrome',
'/usr/bin/google-chrome-stable',
]
for b in binaries:
path = b if os.path.isabs(b) else which(b)
if path:
out = run_cmd([path, '--version'])
ver = parse_version(out)
if ver:
return ver, path
return None, None
def main():
system = platform.system().lower()
ver = None
path = None
if 'windows' in system:
ver, path = windows_version()
elif 'darwin' in system:
ver, path = mac_version()
elif 'linux' in system:
ver, path = linux_version()
else:
print('UNKNOWN: unsupported platform for this checker')
sys.exit(2)
if ver is None:
print('UNKNOWN: Google Chrome not found or version unreadable')
sys.exit(2)
cmp_result = compare_versions(ver, FIXED_VERSION)
ver_str = '.'.join(str(x) for x in ver)
fixed_str = '.'.join(str(x) for x in FIXED_VERSION)
if cmp_result < 0:
print(f'VULNERABLE: Google Chrome {ver_str} detected at {path}; fixed version is {fixed_str}')
sys.exit(1)
else:
print(f'PATCHED: Google Chrome {ver_str} detected at {path}; fixed threshold is {fixed_str}')
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.