This is a peep hole in the browser glass, not a door kicked off its hinges
CVE-2026-11138 is an *uninitialized-use* bug in ANGLE, Chrome's graphics translation layer used by WebGL/GPU rendering. In Chrome versions before 149.0.7827.53 on Linux and before 149.0.7827.53/.54 on Windows/macOS, a malicious site can drive the vulnerable rendering path with crafted HTML and leak cross-origin data that should stay isolated by the browser.
Google's MEDIUM / 6.5 baseline is basically fair. The upside for attackers is broad deployment and zero-auth reach through the web; the downside is heavy real-world friction: user interaction is required, the exploit path depends on ANGLE/GPU behavior, impact is confidentiality-only, and there is no public exploitation or KEV signal. That keeps this in the patch-it bucket, not the drop-everything bucket.
4 steps from start to impact.
Land the victim on attacker-controlled HTML
- Victim runs Chrome older than 149.0.7827.53
- Victim browses to attacker-controlled content
- Normal web access is allowed
- Requires UI:R; there is no drive-by network service to hit directly
- Enterprise email/web filtering can cut initial reach
- Chrome auto-update shrinks dwell time on managed fleets
Exercise the ANGLE rendering path
- ANGLE is in use on the endpoint
- Relevant GPU/rendering features are enabled
- The page successfully triggers the vulnerable code path
- GPU disablement, software rendering fallback, or policy restrictions on WebGL can break the chain
- Platform variance makes browser graphics bugs brittle across a mixed fleet
- Exploit reliability is lower than a pure DOM or JavaScript logic bug
Leak cross-origin data past browser isolation
- Victim has interesting data in browser context worth stealing
- The bug yields readable data rather than just a crash
- Browser isolation defenses are bypassed by the flaw as described
- Impact is confidentiality-only; no integrity or availability win is described
- Leak usefulness depends on what the victim has open or accessible in-session
- Site Isolation and related browser hardening reduce generic cross-origin abuse, so the bug must be exploited precisely
Exfiltrate data over normal web traffic
- The page can make outbound web requests
- Exfiltrated data is small enough to move through ordinary HTTP(S)
- Proxy inspection, CASB, DLP, and browser isolation can reduce or observe exfiltration
- The attacker still walks away with stolen web data, not durable endpoint control
The supporting signals.
| In-the-wild status | No public exploitation evidence found in the sources reviewed; CISA ADP enrichment marks exploitation as none. |
|---|---|
| KEV status | Not listed in the CISA KEV catalog as reviewed. |
| PoC availability | No public PoC located in the sources reviewed. The Chromium issue exists, but bug details may remain restricted until patch uptake improves. |
| EPSS | 0.00035 (~0.035% probability in 30 days, per user-supplied intel); that is *very low* and matches the lack of exploitation chatter. |
| CVSS and what it means | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N = remote via the web, no auth required, but user interaction is mandatory and impact is data exposure only. |
| Affected versions | Google Chrome prior to 149.0.7827.53; Google release notes show desktop fixes landing as 149.0.7827.53 on Linux and 149.0.7827.53/.54 on Windows/macOS. |
| Fixed versions | Patch floor: 149.0.7827.53 (Linux) and 149.0.7827.53/.54 (Windows/macOS). *Downstream Chromium distro backports were not enumerated in the primary sources reviewed.* |
| Exposure / scan signal | Not meaningfully internet-scannable. This is a client-side browser bug, so Shodan/Censys/FOFA/GreyNoise-style exposure counts are low-value for prioritization; fleet inventory and browser version telemetry matter more. |
| Disclosure timeline | Reserved 2026-06-04, published 2026-06-04, updated 2026-06-06 in the official CVE record; Chrome stable desktop release posted 2026-06-02. |
| Reporter / source | Chrome's public release notes list Google as the reporter for the underlying issue 501650354, reported on 2026-04-11. |
noisgate verdict.
The decisive limiter is attack-path friction: the bug is reachable only after a victim loads attacker HTML and the exploit successfully hits a specific ANGLE/GPU rendering path. That is materially different from a remotely reachable server flaw or a browser RCE, so a medium-severity prioritization is the right operational call.
Why this verdict
- Baseline holds: Google's
6.5 / MEDIUMscore already reflects the biggest truth here—remote web delivery with confidentiality impact, but not code execution. - UI:R is real friction: the attacker needs a victim to browse attacker content. That implies phishing, malvertising, or site compromise, and modern email/web controls should stop a chunk of attempts before the bug matters.
- ANGLE path narrows reach: this is not a generic DOM bug. It depends on the vulnerable rendering stack being exercised, which is downward pressure in mixed enterprise fleets with different OS, driver, and browser feature states.
- Blast radius is session-bound: the attacker steals browser-visible data, not endpoint control. The impact can be serious for a logged-in SaaS user, but it does not inherently hand over persistence or lateral movement.
- Threat intel is quiet: no KEV listing, no public exploitation evidence, and no public PoC found. EPSS is extremely low, which argues against inflating this above medium.
Why not higher?
There is no evidence of active exploitation, no known public exploit, and no indication of code execution or sandbox escape. The chain also requires user interaction and a browser-graphics path that is inherently less universal and less reliable than a straight web logic flaw.
Why not lower?
This still crosses an important line: a malicious website may leak cross-origin data from one of the most widely deployed enterprise applications on the planet—the browser. If exploited against users logged into sensitive SaaS apps, the business impact can be real even without malware or local code execution.
What to do — in priority order.
- Force browser auto-update compliance — Use your enterprise browser management stack to enforce Chrome version convergence and identify laggards. Because this is a MEDIUM verdict, there is no mitigation SLA — go straight to the 365-day remediation window, but in practice Chrome is low-friction to update, so you should let the normal managed update channel clear this quickly.
- Apply browser isolation for high-risk users — Put executives, finance, admins, and help desk staff behind remote browser isolation or equivalent controls where you already have it. There is no mitigation SLA for a medium verdict, so treat this as a targeted risk reduction measure rather than a fleet-wide emergency control.
- Restrict WebGL or hardware acceleration where business-tolerable — If you operate kiosk, VDI, or tightly managed admin workstations that do not need rich graphics, consider policy-based reduction of GPU/WebGL exposure to add friction against ANGLE bugs. For this MEDIUM verdict, use it selectively while remediating inside the 365-day window.
- Harden web delivery paths — Tighten URL filtering, ad blocking, sandbox detonation, and email link rewriting to reduce the chance users ever hit hostile HTML. This matters because the most reliable control is stopping step one of the chain.
- Traditional perimeter vulnerability scanning doesn't help much; this is a client-side browser flaw, not an internet-facing service.
- MFA does not stop exploitation of the browser bug itself; it may limit downstream account abuse, but it does not prevent cross-origin leakage from a live browser session.
- Network segmentation is mostly irrelevant; the attacker comes through normal user web browsing, not east-west reachability.
Crowdsourced verification payload.
Run this on the target endpoint or via your software inventory tooling on a representative host. Invoke it with python3 check_chrome_cve_2026_11138.py or python check_chrome_cve_2026_11138.py --path "C:\Program Files\Google\Chrome\Application\chrome.exe"; it needs only normal user privileges and outputs VULNERABLE, PATCHED, or UNKNOWN.
#!/usr/bin/env python3
# check_chrome_cve_2026_11138.py
# Detects whether local Google Chrome is below the fixed version for CVE-2026-11138.
# 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)
COMMON_PATHS = {
'Windows': [
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'),
],
'Darwin': [
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
],
'Linux': [
'/usr/bin/google-chrome',
'/usr/bin/google-chrome-stable',
'/opt/google/chrome/google-chrome',
],
}
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_to_str(v):
return '.'.join(str(x) for x in v)
def get_version_from_binary(path):
try:
out = subprocess.check_output([path, '--version'], stderr=subprocess.STDOUT, timeout=10)
txt = out.decode(errors='ignore').strip()
return parse_version(txt), txt
except Exception:
return None, ''
def candidate_paths(user_path=None):
seen = set()
if user_path:
yield user_path
seen.add(user_path)
chrome_in_path = shutil.which('google-chrome') or shutil.which('google-chrome-stable') or shutil.which('chrome')
if chrome_in_path and chrome_in_path not in seen:
yield chrome_in_path
seen.add(chrome_in_path)
sysname = platform.system()
for p in COMMON_PATHS.get(sysname, []):
if p and p not in seen:
yield p
seen.add(p)
def main():
user_path = None
if len(sys.argv) >= 3 and sys.argv[1] == '--path':
user_path = sys.argv[2]
elif len(sys.argv) == 2 and sys.argv[1] not in ('-h', '--help'):
user_path = sys.argv[1]
elif len(sys.argv) >= 2 and sys.argv[1] in ('-h', '--help'):
print('Usage: python check_chrome_cve_2026_11138.py [--path /path/to/chrome]')
sys.exit(2)
tested = []
for path in candidate_paths(user_path):
if not os.path.exists(path):
continue
ver, raw = get_version_from_binary(path)
tested.append(path)
if ver is None:
continue
if ver < FIXED:
print(f'VULNERABLE: Chrome {version_to_str(ver)} at {path} is below fixed version {version_to_str(FIXED)} for CVE-2026-11138')
sys.exit(1)
else:
print(f'PATCHED: Chrome {version_to_str(ver)} at {path} meets or exceeds fixed version {version_to_str(FIXED)} for CVE-2026-11138')
sys.exit(0)
tested_msg = ', '.join(tested) if tested else 'no candidate binaries found'
print(f'UNKNOWN: Unable to determine Chrome version ({tested_msg})')
sys.exit(2)
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.