This is a sharp blade hidden inside a web page, not a grenade tossed through your firewall
CVE-2026-11066 is an improper input validation flaw in Chrome's ANGLE graphics layer that can let a remote attacker *potentially perform a sandbox escape* through a crafted HTML page. Affected desktop builds are Chrome prior to 149.0.7827.53 on Linux and prior to 149.0.7827.53/.54 on Windows and macOS, based on Google's June 2026 release notes and NVD's affected CPE range.
The vendor-side scoring says CRITICAL 9.6, but the real-world shape is narrower: this is a client-side, user-driven browser exploit path, not an unauthenticated internet-facing service bug. Chromium itself labeled it Medium, there is no KEV entry, no public exploitation evidence surfaced in the sources reviewed, and the EPSS supplied is extremely low, so this deserves a downgrade from panic-tier to important-but-routine enterprise browser patching.
3 steps from start to impact.
Deliver a crafted web page
- Target is running vulnerable Chrome desktop builds before
149.0.7827.53 - User interaction occurs (
UI:R) by opening or being redirected to the malicious page - ANGLE-reachable rendering path is available in the victim browser session
- Secure web gateways, browser isolation, URL filtering, and phishing-resistant user workflows cut reachability
- This is endpoint-delivered; there is no broad internet scanning or mass exploit spray against a single TCP service
- Chrome auto-update collapses exposure windows quickly in well-managed fleets
Trigger the ANGLE validation flaw
- Exploit reliably reaches the vulnerable ANGLE path
- Victim environment is susceptible to the specific rendering conditions the exploit expects
- Browser sandbox escape chains are typically less reliable than ordinary renderer bugs
- Hardware/driver/rendering differences can make real-world weaponization brittle
- No public PoC was found in the sources reviewed, which usually slows copycat exploitation
Convert browser compromise into endpoint impact
- Successful sandbox escape, not just renderer compromise or denial of service
- Victim endpoint has meaningful downstream access or data worth stealing
- EDR, application control, privilege management, and browser isolation can limit post-exploit follow-on actions
- Blast radius is bounded to compromised endpoints; there is no inherent fleet-wide wormability in the CVE description
The supporting signals.
| In-the-wild status | No evidence of active exploitation was found in the reviewed sources, and the CVE is not in CISA KEV as of 2026-06-05. |
|---|---|
| Public PoC availability | No public GitHub or researcher PoC surfaced in the web review. That does not mean none exists privately, but there is no obvious copy-paste exploit signal yet. |
| EPSS | 0.00047 (~0.047% probability over 30 days, per user-supplied intel). Percentile was not authoritatively confirmed in the reviewed sources. |
| KEV status and dates | Not KEV-listed. Reviewed against the CISA KEV catalog on 2026-06-05. |
| CVSS vector meaning | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H means remote delivery with no auth, but it still needs user interaction and aims for cross-sandbox impact rather than a simple tab crash. |
| Vendor vs. Chromium severity | NVD shows CISA-ADP 9.6 / CRITICAL, while the vulnerability description itself states Chromium security severity: Medium. That mismatch is the main clue to reassess rather than inherit the top-line score. |
| Affected versions | Chrome prior to 149.0.7827.53 on Linux, and prior to 149.0.7827.53/.54 on Windows and macOS, per Google's stable release note and NVD. |
| Fixed versions / backports | Fixed in 149.0.7827.53 (Linux) and 149.0.7827.53/54 (Windows/macOS). No distro-specific backport details were identified in the reviewed sources. |
| Scanning / exposure data | This is not meaningfully Shodan/Censys/FOFA-scannable because Chrome is endpoint software, not an internet-facing service. Exposure is determined by fleet versioning and user browsing, not open ports. |
| Disclosure / reporter | Disclosed 2026-06-04 in NVD intake; Google's stable release notes say reported by Google on 2026-04-03 under bug 499124128. |
noisgate verdict.
The decisive downgrade factor is that this bug requires the user to browse into the exploit path; it is not a remotely reachable server flaw that an attacker can spray across the enterprise from the outside. It still lands in HIGH because Chrome is ubiquitous and the stated impact is a potential sandbox escape, which can turn a single web visit into endpoint compromise.
Why this verdict
- User interaction requirement pulls this down:
UI:Rmeans the attacker still needs a lure, redirect, or malicious site visit. That is a real choke point modern web filtering, isolation, and user workflow controls can disrupt. - Client-side delivery narrows exposed population: this is a browser-on-endpoints problem, not a public-facing appliance or server bug. There is no broad unauthenticated internet attack surface to sweep with scanners, which reduces operational exploitability at enterprise scale.
- Exploit signal is weak so far: no KEV listing, no public PoC found, and the supplied EPSS of
0.00047is extremely low. That combination argues against inheriting the full9.6panic score. - Chromium's own label matters: the CNA description explicitly says *Chromium security severity: Medium*. When the upstream product team and the CVSS math disagree this sharply, practitioners should trust the friction in the attack path, not the abstract impact ceiling.
Why not higher?
There is no current evidence of in-the-wild exploitation, no KEV listing, and no public exploit artifact in the reviewed sources. More importantly, the bug is still gated behind a user browsing event, which materially changes patch priority versus remotely reachable pre-auth server CVEs.
Why not lower?
A browser-to-endpoint sandbox escape is not hygiene fluff. Chrome is deployed everywhere, the attacker needs no credentials, and a successful hit can compromise a workstation with all the downstream identity and data access that implies.
What to do — in priority order.
- Force Chrome auto-update and restart compliance — Use Chrome Enterprise policy, MDM, or endpoint management to ensure browsers move to
149.0.7827.53/54or later and actually relaunch. For a HIGH verdict, put this control in place within 30 days if your normal update ring is not already enforcing it. - Restrict risky browsing paths for privileged users — Route admin, developer, and help-desk browsing through browser isolation or a stricter SWG policy, and block untrusted categories that commonly deliver exploit kits or lures. This reduces the only mandatory prerequisite—user exposure to a crafted page—and should be deployed within 30 days.
- Reduce unnecessary graphics attack surface on high-risk tiers — For hardened admin workstations, kiosks, and VDI pools, consider disabling or tightly controlling WebGL / GPU-accelerated browsing where business impact is acceptable. This is not universal advice for every employee desktop, but it is a practical risk reducer for sensitive tiers and should be evaluated within 30 days.
- Query fleet inventory for stale versions — Pull browser version telemetry from EDR, software inventory, or Chrome Browser Cloud Management and flag anything below the fixed builds. Because network scanners will not see this well, endpoint inventory is your primary compensating visibility control and should be active within 30 days.
- A perimeter vulnerability scan will not materially help; this is endpoint browser software, not an exposed network service.
- MFA does not block the exploit path; it may help after compromise, but it does nothing to stop a malicious page from triggering the bug.
- A classic WAF is mostly irrelevant because the vulnerable code executes in the browser, not in your inbound web stack.
Crowdsourced verification payload.
Run this on the target endpoint or via your software-distribution/EDR scripting channel. Invoke it with python3 chrome_cve_2026_11066_check.py; no administrator privileges are required, but the script needs permission to execute local binaries from standard install paths and read the macOS app bundle metadata if present.
#!/usr/bin/env python3
# CVE-2026-11066 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
from shutil import which
THRESHOLD = (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 run_cmd(cmd):
try:
p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=10)
out = (p.stdout or '') + ' ' + (p.stderr or '')
return out.strip()
except Exception:
return ''
def candidate_commands():
system = platform.system()
cmds = []
if system == 'Windows':
local = os.environ.get('LOCALAPPDATA', '')
pf = os.environ.get('ProgramFiles', '')
pfx86 = os.environ.get('ProgramFiles(x86)', '')
paths = [
os.path.join(local, 'Google', 'Chrome', 'Application', 'chrome.exe'),
os.path.join(pf, 'Google', 'Chrome', 'Application', 'chrome.exe'),
os.path.join(pfx86, 'Google', 'Chrome', 'Application', 'chrome.exe'),
]
for p in paths:
if p and os.path.exists(p):
cmds.append([p, '--version'])
elif system == 'Darwin':
app_bin = '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'
if os.path.exists(app_bin):
cmds.append([app_bin, '--version'])
plist = '/Applications/Google Chrome.app/Contents/Info.plist'
if os.path.exists(plist):
cmds.append(['/usr/bin/defaults', 'read', plist, 'CFBundleShortVersionString'])
else:
for name in ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser']:
p = which(name)
if p:
cmds.append([p, '--version'])
for p in ['/opt/google/chrome/chrome', '/usr/bin/google-chrome', '/usr/bin/google-chrome-stable']:
if os.path.exists(p):
cmds.append([p, '--version'])
return cmds
def main():
versions = []
checked = []
for cmd in candidate_commands():
checked.append(' '.join(cmd))
out = run_cmd(cmd)
v = parse_version(out)
if v:
versions.append((v, ' '.join(cmd), out.strip()))
if not versions:
print('UNKNOWN - could not determine Chrome version from common install paths')
if checked:
print('Checked:', '; '.join(checked))
sys.exit(2)
# Use highest discovered version if multiple installs exist.
versions.sort(key=lambda x: x[0], reverse=True)
version, source, raw = versions[0]
if version < THRESHOLD:
print(f'VULNERABLE - detected Chrome version {raw} via {source}; fixed version is >= 149.0.7827.53')
sys.exit(1)
else:
print(f'PATCHED - detected Chrome version {raw} via {source}; fixed version threshold is >= 149.0.7827.53')
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
149.0.7827.53, confirm your update rings are not stuck behind deferred restarts, and focus first on privileged users plus unmanaged or exception-based endpoints. For this HIGH call, the noisgate mitigation SLA is within 30 days for temporary risk reduction like enforced browser relaunch, stricter web filtering, or isolation for sensitive users, and the noisgate remediation SLA is within 180 days for the actual vendor fix—but because this is a browser with broad endpoint exposure, most enterprises should complete rollout far sooner through normal Chrome auto-update controls.Sources
- NVD CVE-2026-11066
- Chrome Releases: Stable Channel Update for Desktop (June 2, 2026)
- Chrome Releases: Early Stable Update for Desktop / label page
- Chrome Enterprise: Manage Chrome updates (Windows)
- Chrome Enterprise: Manage the Chrome variations framework
- CISA Known Exploited Vulnerabilities Catalog
- VulDB entry for CVE-2026-11066
- SecurityWeek coverage of Chrome 149 security fixes
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.