This is a peephole in a moving car, not a stolen ignition key
CVE-2026-11137 is an *uninitialized use* bug in Chrome's ANGLE graphics layer that affects Google Chrome versions prior to 149.0.7827.53 on Linux and 149.0.7827.53/54 on Windows and macOS. A malicious site can trigger the flaw through crafted web content and potentially disclose data from process memory, which is an information leak rather than direct code execution.
Google's MEDIUM label is basically fair. The attack starts remotely and Chrome is ubiquitous, but the real-world chain still requires *user interaction* and the technical impact is limited to confidentiality leakage from browser process memory; there is no public evidence here of sandbox escape, arbitrary code execution, or in-the-wild exploitation.
4 steps from start to impact.
Lure a user to attacker-controlled web content
- Target is running a vulnerable Chrome build prior to
149.0.7827.53(149.0.7827.54on Win/Mac is also fixed) - Victim visits or renders attacker-controlled content
- ANGLE-relevant rendering path is reachable in that browsing session
- Requires user interaction (
UI:R), which immediately narrows abuse versus wormable browser-server bugs - Enterprise URL filtering, ad blocking, safe browsing, email security, and browser isolation reduce how often crafted content is reached
- Chrome auto-update shrinks dwell time on managed fleets faster than typical server-side CVEs
Trigger uninitialized memory use in ANGLE
- The specific buggy ANGLE path is exercised on the victim platform
- Chrome process has memory contents worth leaking at the moment of access
- Graphics-path bugs can be platform- and driver-sensitive, which hurts reliability across a heterogeneous enterprise fleet
- Browser hardening and sandboxing mean a renderer bug does not automatically become system compromise
Recover sensitive process memory
- Leaked memory region contains useful data
- Attacker can parse and stabilize the leaked bytes
- Information leaks are inherently noisier and less deterministic than a straight RCE primitive
- The value of the leak depends heavily on what happened to be in memory during that session
Exfiltrate the recovered data
- Attacker controls a callback endpoint
- The browser session can make outbound requests
- DLP, proxy inspection, browser isolation, and egress controls can catch or block obvious exfil paths
- Without a second vulnerability, blast radius usually stays within the browser/session scope
The supporting signals.
| In-the-wild status | No confirmed in-the-wild exploitation found in the reviewed sources, and Google did not annotate this issue as exploited. As of 2026-06-06, it is not present in CISA KEV. |
|---|---|
| PoC availability | No public PoC or Metasploit module was located in the reviewed primary references. The Chromium issue is still access-restricted, which usually means repro details are intentionally withheld until patch uptake improves. |
| EPSS | User-supplied EPSS is 0.00035, which is extremely low in absolute probability terms. FIRST documents EPSS semantics, but the percentile for this CVE was not independently verified in the reviewed sources. |
| KEV status | Not KEV-listed as of 2026-06-06. That matters because CISA KEV is the strongest public signal that exploitation has crossed from theoretical to operational. |
| CVSS vector meaning | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N means remote, low-complexity trigger, no privileges, but user interaction is required and impact is confidentiality-only with no integrity or availability component. |
| Affected versions | Chrome before 149.0.7827.53 is affected on Linux; Windows and macOS builds before 149.0.7827.53/54 are covered by the Chrome stable advisory cadence. |
| Fixed versions | Fixed in Chrome 149.0.7827.53 for Linux and 149.0.7827.53/.54 for Windows/macOS per Google's stable release notes. *Inference:* distro-packaged Chromium may ship the fix as a downstream backport on a different package version, so track distro advisories separately. |
| Scanning / exposure data | Shodan/Censys/GreyNoise-style internet exposure is not the right lens here because this is a client-side browser bug, not a listening service with a bannable footprint. Exposure is driven by endpoint version inventory and browsing activity, not open ports. |
| Disclosure timeline | Disclosed on 2026-06-04 in NVD after Google published the Chrome 149 stable update on 2026-06-02. |
| Reporter | Reported by Google on 2026-04-11 in the Chrome stable advisory rollup, not by an external researcher receiving a bounty. |
noisgate verdict.
The decisive factor is that this bug is a *user-driven confidentiality leak* in a browser component, not an externally reachable service-side compromise or a published code-execution chain. Chrome's ubiquity keeps the issue relevant, but the lack of exploitation evidence and the need for the victim to render attacker-controlled content prevent this from climbing into HIGH.
Why this verdict
- Start at vendor 6.5: Google already put this in
MEDIUM, which is a reasonable baseline for a remote browser info-leak in a massively deployed product. - User interaction pulls down:
UI:Rmeans the attacker needs a victim to load malicious content; that is materially weaker than drive-by-free server exploitation or zero-click messaging paths. - Impact is confidentiality-only: the published vector has
C:H/I:N/A:N, so this is not a direct integrity or availability event and not a published RCE or sandbox escape. - No exploit pressure signal: no KEV listing, no reviewed public PoC, and a very low user-supplied EPSS materially reduce near-term operational urgency.
- But exposure is broad: Chrome is everywhere, externally influenced by normal browsing, and the vulnerable component is in a routine rendering path, which keeps this out of LOW.
Why not higher?
To justify HIGH, you would want at least one of these amplifiers: active exploitation, a public reliable PoC, zero-click reachability, or impact that crosses into code execution or sandbox escape. None of those are present in the reviewed record. This is a browser memory disclosure bug with user interaction and no current evidence of operational weaponization.
Why not lower?
LOW would underrate the fact that Chrome is one of the widest client-side attack surfaces in the enterprise and this bug is remotely triggerable through ordinary web content. Even without code execution, a confidentiality leak from browser process memory can expose session material or sensitive page data, so it still deserves normal patch-cycle attention.
What to do — in priority order.
- Enforce browser auto-update — Make sure managed Chrome channels cannot lag behind the fixed
149.0.7827.53/54builds. For aMEDIUMverdict there is no mitigation SLA — go straight to the 365-day remediation window, but for browsers you should still verify update policy and stale endpoints now because version drift is the only clean exposure metric. - Block unmanaged Chrome versions — Use EDR, MDM, or NAC policy to identify endpoints running vulnerable Chrome versions and push them into a corrective workflow. There is no separate mitigation clock here, so use this as hygiene control while completing remediation within the
MEDIUM365-day window. - Prefer browser isolation for risky browsing tiers — Apply remote browser isolation or hardened browsing profiles to high-risk user groups such as finance, executives, and external-content-heavy roles. This does not replace patching, but it lowers exploit reliability and helps until the fleet is uniformly remediated within the 365-day window.
- Monitor browser-version exceptions — Build an exception report for hosts pinned to legacy Chrome versions, disabled auto-update, kiosk modes, VDI gold images, or software-distribution failures. Those long-tail systems are where medium browser flaws quietly persist.
- A perimeter firewall does not solve this; the trigger arrives through normal user web browsing over allowed outbound paths.
- Network vuln scanning will not reliably prove exploitability because this is a client-side rendering issue, not a remotely bannered service.
- MFA is good security hygiene, but it does not stop memory disclosure in the browser process once a victim renders malicious content.
Crowdsourced verification payload.
Run this on the target endpoint or through your fleet remote-execution tool. Invoke it with python3 check_cve_2026_11137.py on macOS/Linux or py check_cve_2026_11137.py on Windows; it needs only standard user privileges and will print VULNERABLE, PATCHED, or UNKNOWN based on the locally installed Google Chrome version.
#!/usr/bin/env python3
# check_cve_2026_11137.py
# Detects whether installed Google Chrome is vulnerable to CVE-2026-11137.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import subprocess
import sys
from typing import Optional, Tuple
PATCHED = (149, 0, 7827, 53)
def parse_version(text: str) -> Optional[Tuple[int, int, int, int]]:
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, capture_output=True, text=True, timeout=10)
if p.returncode == 0:
return (p.stdout or p.stderr).strip()
except Exception:
pass
return None
def windows_candidates():
return [
os.path.join(os.environ.get('ProgramFiles', r'C:\Program Files'), 'Google', 'Chrome', 'Application', 'chrome.exe'),
os.path.join(os.environ.get('ProgramFiles(x86)', r'C:\Program Files (x86)'), 'Google', 'Chrome', 'Application', 'chrome.exe'),
os.path.join(os.environ.get('LocalAppData', ''), 'Google', 'Chrome', 'Application', 'chrome.exe'),
]
def mac_candidates():
return [
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
]
def linux_candidates():
return ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser']
def get_version() -> Optional[Tuple[int, int, int, int]]:
system = platform.system().lower()
if system == 'windows':
for path in windows_candidates():
if os.path.exists(path):
out = run_cmd([path, '--version'])
if out:
v = parse_version(out)
if v:
return v
# Fallback to registry query via PowerShell if binary path is nonstandard
ps = [
'powershell', '-NoProfile', '-Command',
r"$paths=@('HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe','HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe','HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe'); foreach($p in $paths){ try { $x=(Get-ItemProperty $p).'(default)'; if($x){ & $x --version; exit 0 } } catch {} }; exit 1"
]
out = run_cmd(ps)
if out:
return parse_version(out)
elif system == 'darwin':
for path in mac_candidates():
if os.path.exists(path):
out = run_cmd([path, '--version'])
if out:
v = parse_version(out)
if v:
return v
else:
for cmd in linux_candidates():
out = run_cmd([cmd, '--version'])
if out:
v = parse_version(out)
if v:
return v
return None
def main():
version = get_version()
if not version:
print('UNKNOWN: Google Chrome version could not be determined on this host')
sys.exit(2)
version_str = '.'.join(str(x) for x in version)
if version < PATCHED:
print(f'VULNERABLE: installed Chrome version {version_str} is older than 149.0.7827.53')
sys.exit(1)
else:
print(f'PATCHED: installed Chrome version {version_str} is at or above 149.0.7827.53')
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
149.0.7827.53/.54, and clear long-tail exceptions in your standard browser patch cycle. Because this is MEDIUM, there is no noisgate mitigation SLA — go straight to the 365-day remediation window; finish the actual Chrome update within the noisgate remediation SLA of 365 days, though in practice most mature fleets should close this far sooner through routine browser servicing.Sources
- NVD CVE-2026-11137
- Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
- Chrome Releases - Early Stable Update for Desktop (May 29, 2026)
- Chromium issue 501647943
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS overview
- Canadian Centre for Cyber Security advisory AV26-544
- Chromium severity guidelines
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.