This is a lockpick for the second door, not a front-door battering ram
CVE-2026-11065 is a use-after-free bug in Chrome's ANGLE graphics layer, fixed in Chrome 149.0.7827.53 on Linux and 149.0.7827.53/54 on Windows and macOS. The supplied CVE text says the bug only matters after an attacker has already compromised the renderer process, which makes this a *sandbox-escape stage* in a browser exploit chain rather than a standalone initial-access bug.
The vendor-style 9.6/CRITICAL label does not match field reality. Google's own June 2, 2026 stable release post classifies CVE-2026-11065 as Medium, and that is the right anchor: the decisive friction is the prerequisite of a separate renderer exploit first, which sharply narrows reachable attackers, affected sessions, and practical exploit volume despite the scary worst-case impact once chained.
4 steps from start to impact.
Gain renderer execution with a separate bug
- Victim visits attacker-controlled content or otherwise processes hostile web content
- A separate renderer-compromise primitive exists and succeeds first
- This is already one successful exploit stage before CVE-2026-11065 even enters the picture
- Modern browser mitigations, site isolation, and crash telemetry kill many chains before they become reliable
Drive ANGLE into the vulnerable lifetime bug
- ANGLE code path reachable on the target build
- Exploit can shape heap state reliably enough to reuse freed memory
- Graphics-path bugs are often crash-prone and hardware/driver dependent
- GPU blacklisting, disabled acceleration, or differing platform behavior can break reliability across fleets
libGLESv2/ANGLE modules, or exploit-guard events; traditional network IDS has poor visibility.Cross the sandbox boundary
- Successful memory-corruption control from the ANGLE bug
- A viable path from renderer to a less-restricted process or host context
- Chrome sandboxing, CFG/CET/ASLR, and platform hardening raise the bar materially
- Many exploit attempts die as renderer crashes without achieving a durable sandbox escape
Operationalize host impact
- Successful sandbox escape
- Useful user context and an endpoint not blocked by EDR/application control
- Standard-user desktops, EDR containment, and application control still limit payoff
- This remains a client-side compromise path, not a wormable network-service event
The supporting signals.
| In-the-wild status | No current evidence of active exploitation in primary sources. Google did not flag this release as a zero-day, and CISA KEV does not list CVE-2026-11065 as of 2026-06-05. |
|---|---|
| PoC availability | No public weaponized PoC located in primary sources. The Chromium issue exists but details are restricted, which is normal until patch adoption improves. |
| EPSS | 0.00035 from the supplied intel block; *very low expected short-term exploitation probability*. Percentile was not supplied in the prompt. |
| KEV status | Not KEV-listed. That removes the strongest urgency amplifier for enterprise patch triage. |
| Vendor vs. Google severity | The supplied intel says CRITICAL 9.6 with AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H, but Google's June 2, 2026 stable release post labels CVE-2026-11065 as Medium. For this CVE, Google's rating better reflects the real prerequisite chain. |
| Affected versions | Google states the fix shipped in Chrome 149.0.7827.53 (Linux) and 149.0.7827.53/54 (Windows/Mac), so earlier desktop builds are affected. |
| Fixed versions | Patch floor: 149.0.7827.53 or newer. Treat any managed desktop browser below that floor as vulnerable. |
| Scanning / exposure | Not Shodan/Censys-addressable in any useful way. This is a client-side browser flaw, not a listening network service, so external exposure counts are a poor prioritization signal. |
| Disclosure timeline | There is a date mismatch worth calling out: Google shipped the fix on 2026-06-02 in the stable channel post, while the supplied intel says disclosed 2026-06-04. That usually means downstream CVE publication lagged the vendor patch release. |
| Reporter | Google's release post says Reported by Google on 2026-04-03. |
noisgate verdict.
The single biggest severity reducer is the renderer-compromise prerequisite. If an attacker already needs a separate successful browser exploit before this bug matters, then this CVE is a post-initial-access chain component, not a frontline enterprise patch emergency by itself.
Why this verdict
- Renderer compromise required: starting from the supplied 9.6 baseline, the biggest downward adjustment is that the attacker must already own the renderer first. That implies a prior exploit stage succeeded, which massively narrows who can actually use this bug.
- Client-side and non-scannable: Chrome is everywhere, but this is not a remotely reachable service you can sweep from the internet. Reachability depends on user browsing plus exploit-chain quality, which cuts practical abuse volume.
- No exploitation evidence: no KEV listing, no zero-day language from Google, and a very low supplied EPSS score all push urgency down further.
- Google itself scored it Medium: when Google's release notes and downstream CVSS-style metadata disagree, the vendor's product-context severity is usually the better guide for browser chain bugs like this.
Why not higher?
It is not higher because this CVE is not a standalone initial-access event. A bug that requires prior renderer compromise is, by definition, a second-stage exploit component whose real-world population is smaller than a true unauthenticated remote code execution flaw.
Why not lower?
It is not lower because sandbox-escape primitives in Chrome still matter a lot when they *do* chain cleanly. Chrome is widely deployed, ANGLE sits on a security-sensitive graphics path, and a working exploit would materially raise attacker payoff from a renderer foothold.
What to do — in priority order.
- Keep Chrome auto-update unblocked — Make sure update policies, version pinning, and software-distribution rings are not freezing browsers below
149.0.7827.53. For a MEDIUM noisgate verdict there is no mitigation SLA — go straight to the 365-day remediation window, but fixing broken update channels should happen in normal browser hygiene immediately because it reduces exposure to the whole Chrome bug bundle, not just this CVE. - Restrict unnecessary WebGL/GPU access where feasible — On high-risk kiosks, VDI pools, and tightly managed admin workstations, consider temporarily reducing unneeded graphics exposure if business workflows allow it. This is a niche compensating control only; there is no noisgate mitigation SLA for MEDIUM, so use it selectively while patching inside the 365-day remediation window.
- Hunt for Chrome crash clusters — Pull browser and EDR telemetry for repeated renderer/GPU-process crashes, especially ANGLE- or
libGLESv2-related faults, because exploit development against lifetime bugs is noisy before it is reliable. Do this in routine monitoring; again, there is no noisgate mitigation SLA for MEDIUM unless active exploitation emerges. - Focus exceptions on frozen images — Audit VDI, kiosk, gold-image, and offline endpoints where Chrome auto-update is commonly disabled or delayed. Those populations are where a Medium browser CVE quietly turns into long-lived exposure over the 365-day remediation window.
- WAFs and perimeter IPS do not meaningfully help because this is a client-side browser exploit stage, not a server-side web attack surface.
- External attack-surface scanners will not show you exposure in any useful sense; the problem is browser version state on endpoints.
- MFA is good security hygiene but irrelevant to the exploit path described here.
Crowdsourced verification payload.
Run this on the target endpoint or through your software-distribution/endpoint-management tooling. Invoke it with python3 check_chrome_cve_2026_11065.py on macOS/Linux or py check_chrome_cve_2026_11065.py on Windows; no admin rights are required unless your EDR blocks process inspection.
#!/usr/bin/env python3
# check_chrome_cve_2026_11065.py
# Detects whether local Google Chrome is below the fixed version for CVE-2026-11065.
# 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 run_version(path):
try:
p = subprocess.run([path, '--version'], capture_output=True, text=True, timeout=5)
out = (p.stdout or '') + ' ' + (p.stderr or '')
return parse_version(out)
except Exception:
return None
def candidates():
system = platform.system()
paths = []
if system == 'Windows':
for envvar in ('PROGRAMFILES', 'PROGRAMFILES(X86)', 'LOCALAPPDATA'):
base = os.environ.get(envvar)
if base:
paths.append(os.path.join(base, 'Google', 'Chrome', 'Application', 'chrome.exe'))
elif system == 'Darwin':
paths.extend([
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
])
else:
for name in ('google-chrome', 'google-chrome-stable', 'chrome'):
found = shutil.which(name)
if found:
paths.append(found)
paths.extend([
'/usr/bin/google-chrome',
'/usr/bin/google-chrome-stable',
'/opt/google/chrome/chrome',
])
seen = []
unique = []
for p in paths:
if p not in seen:
seen.append(p)
unique.append(p)
return unique
def main():
found_any = False
for path in candidates():
if not os.path.exists(path) and not shutil.which(path):
continue
ver = run_version(path)
if ver is None:
continue
found_any = True
print(f'FOUND: {path}')
print('VERSION: %d.%d.%d.%d' % ver)
print('FIXED_AT: %d.%d.%d.%d' % FIXED)
if ver >= FIXED:
print('PATCHED')
sys.exit(0)
else:
print('VULNERABLE')
sys.exit(1)
if not found_any:
print('UNKNOWN')
print('Google Chrome not found or version could not be determined.')
sys.exit(2)
if __name__ == '__main__':
main()
If you remember one thing.
149.0.7827.53, fix channel/update-policy drift, and close the laggard population through normal browser maintenance rather than burning an out-of-band patch cycle.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.