This is a peephole in the browser sandbox, not a front door into the enterprise
CVE-2026-11104 is an uninitialized-use bug in ANGLE affecting Google Chrome versions prior to 149.0.7827.53 on desktop release trains associated with that fix. In plain terms, once an attacker already has code execution inside Chrome's renderer process, a crafted HTML page can coax ANGLE into exposing uninitialized process memory and potentially reveal sensitive data from that renderer.
Google's MEDIUM/6.5 baseline is defensible in a vacuum, but it overstates operational urgency for enterprise patch queues. The decisive friction is the prerequisite: the attacker must *already have compromised the renderer process*, which means this is not an initial-access bug and not a standalone browser takeover; it is a post-compromise information leak that matters mostly as part of a larger exploit chain.
4 steps from start to impact.
Land a separate renderer compromise
- User visits attacker-controlled content
- Attacker has a separate working renderer-compromise exploit
- Target is running a vulnerable Chrome build
- This CVE is not an entry point
- Modern Chrome hardening, site isolation, and rapid browser updates raise the bar for landing stage one
- Exploit developers must spend a real exploit just to reach this bug
Trigger the ANGLE uninitialized read
- Renderer compromise already achieved
- ANGLE code path reachable on the target platform/build
- Attacker can deliver crafted page content to the active browser session
- ANGLE behavior can vary by platform, GPU stack, driver path, and build
- Uninitialized-use disclosures are often less deterministic than clean memory corruption primitives
- Browser restarts and version churn break exploit reliability quickly
Extract useful process memory
- Leak returns stable and parseable memory contents
- Valuable secrets are present in renderer memory
- Attacker can exfiltrate or reuse disclosed data
- Leaked bytes may be noisy, partial, or low value
- Renderer memory scope is narrower than full browser or OS compromise
- Data usefulness is highly situational
Chain the leak into something bigger
- Attacker has another primitive that benefits from leaked memory
- Leaked data materially improves exploit reliability or access
- Target session contains high-value data
- Requires a second bug or meaningful post-leak objective
- Not every renderer compromise needs this helper primitive
- Blast radius usually remains within the browser session, not the enterprise fleet
The supporting signals.
| In-the-wild status | No public evidence of active exploitation found in reviewed sources, and the user-provided intel says KEV listed: No. |
|---|---|
| KEV status | Not in CISA KEV as of the reviewed catalog source; no emergency exploitation signal from KEV. |
| PoC availability | No public PoC or named researcher exploit repository surfaced in reviewed sources. The Chromium issue exists at issue 500501226 but is access-restricted. |
| EPSS | 0.00035 from the user-provided intel, which is *extremely low* on its face; I did not independently verify the percentile value from a live API response in this workflow. |
| CVSS vector meaning | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N translates to web-deliverable content plus user interaction, with impact limited to confidentiality. That still overstates real enterprise urgency because the description adds a non-CVSS prerequisite: the renderer must already be compromised. |
| Affected versions | Google Chrome prior to 149.0.7827.53; the official Chrome release post ties the desktop early stable update to 149.0.7827.53/.54 depending on platform. |
| Fixed versions | Google patched in Chrome 149.0.7827.53 on the release line cited by the Chrome Releases post. For browser derivatives, do not assume upstream Chromium version parity means identical fix timing. |
| Exposure reality | Shodan/Censys/GreyNoise style internet census is not meaningful here because Chrome is endpoint client software, not an externally enumerable server surface. Your exposure question is fleet version inventory, not internet attack-surface count. |
| Disclosure date | Published 2026-06-04 in the CVE record mirrored by CIRCL. |
| Reporting / provenance | Public provenance is thin: the Chrome CNA CVE record references the Chrome release advisory and a Chromium issue, but the accessible sources reviewed do not expose a public reporter credit. |
noisgate verdict.
The single biggest severity killer is the attacker position requirement: this bug only matters after a renderer compromise already exists. That makes it a chain helper with narrow standalone value, and that is not where a 10,000-host patch program should spend scarce urgency.
Why this verdict
- Requires prior renderer compromise: attacker position is not unauthenticated remote entry; it implies a separate exploit has already beaten Chrome's renderer boundary, which is major downward pressure on severity.
- Client-side exposure is broad but reachable population for the vulnerable step is narrow: many enterprises run Chrome, but only a tiny subset of sessions will ever reach this bug because an earlier compromise stage must already exist.
- Impact is confidentiality-only: this is a memory disclosure primitive, not direct sandbox escape, OS code execution, or persistence by itself.
- Threat intel is cold: no KEV listing, no reviewed public exploitation evidence, and user-provided EPSS is extremely low.
- Modern controls should stop earlier steps: browser updates, exploit mitigations, EDR, and web filtering are more likely to matter against the initial renderer exploit than against this leak primitive itself.
Why not higher?
If this were a one-click renderer RCE or a sandbox escape, the score would climb fast because Chrome is everywhere. But this CVE sits behind a prior compromise requirement, and that prerequisite compounds heavily in real deployments. It is a helper primitive, not the breach opener.
Why not lower?
It is not IGNORE because browser exploit chains are real, and information leaks can materially improve exploit reliability or expose session data. On a fleet this large, browsers are high-churn attack targets, so even low-priority chain components still deserve routine hygiene tracking.
What to do — in priority order.
- Enforce browser auto-update and relaunch compliance — Make sure Chrome's enterprise update controls are actually moving endpoints to
149.0.7827.53or later and that users relaunch the browser so the fix is loaded. For aLOWverdict there is no mitigation SLA and no remediation SLA beyond backlog hygiene, so handle this in the next normal browser hygiene sweep rather than disrupting higher-risk work. - Prioritize high-risk user tiers for version cleanup — Focus first on admins, developers, finance, and users who regularly browse untrusted content, because browser exploit chains hurt most where session value is highest. Even at
LOW, these cohorts are where a chained information leak is most likely to matter. - Monitor browser crash and exploit telemetry — Collect Chrome crash data, EDR browser exploit alerts, and suspicious renderer/process ancestry because direct detection of the leak is poor. This helps you catch the *preceding* renderer compromise step, which is the real choke point.
- Use isolation for risky browsing paths — Remote browser isolation or hardened VDI for internet-facing admin activity reduces the value of browser exploit chains by separating risky browsing from privileged sessions. Treat this as structural risk reduction, not an emergency mitigation for this specific CVE.
- A WAF does not help; this is client-side browser processing, not a server endpoint bug.
- Perimeter vulnerability scanning will not measure exposure; Chrome is not internet-enumerable in the way a VPN or web server is.
- MFA is good hygiene but does not prevent a compromised renderer from reading process memory already present in the browser.
Crowdsourced verification payload.
Run this on the target endpoint or via your desktop management tooling with local user rights; admin is usually not required unless your EDR blocks registry/process inspection. Invoke it with python3 check_chrome_cve_2026_11104.py on macOS/Linux or py check_chrome_cve_2026_11104.py on Windows; it checks common Chrome install locations/registry keys and prints VULNERABLE, PATCHED, or UNKNOWN.
#!/usr/bin/env python3
# check_chrome_cve_2026_11104.py
# Detects whether local Google Chrome appears vulnerable to CVE-2026-11104
# Exit codes:
# 0 = PATCHED
# 1 = VULNERABLE
# 2 = UNKNOWN
import os
import platform
import re
import shutil
import subprocess
import sys
TARGET = (149, 0, 7827, 53)
VERSION_RE = re.compile(r'(\d+)\.(\d+)\.(\d+)\.(\d+)')
def parse_version(text):
if not text:
return None
m = VERSION_RE.search(text)
if not m:
return None
return tuple(int(x) for x in m.groups())
def cmp_version(a, b):
if a == b:
return 0
return -1 if a < b else 1
def run_cmd(cmd):
try:
p = subprocess.run(cmd, capture_output=True, text=True, timeout=10)
out = (p.stdout or '') + ' ' + (p.stderr or '')
return out.strip()
except Exception:
return ''
def check_windows_registry():
try:
import winreg
except Exception:
return None, None
reg_paths = [
(winreg.HKEY_CURRENT_USER, r'SOFTWARE\Google\Chrome\BLBeacon'),
(winreg.HKEY_LOCAL_MACHINE, r'SOFTWARE\Google\Chrome\BLBeacon'),
(winreg.HKEY_LOCAL_MACHINE, r'SOFTWARE\WOW6432Node\Google\Chrome\BLBeacon'),
]
for hive, path in reg_paths:
try:
key = winreg.OpenKey(hive, path)
version, _ = winreg.QueryValueEx(key, 'version')
parsed = parse_version(version)
if parsed:
return version, parsed
except Exception:
continue
return None, None
def check_windows_files():
candidates = [
os.path.expandvars(r'%ProgramFiles%\Google\Chrome\Application\chrome.exe'),
os.path.expandvars(r'%ProgramFiles(x86)%\Google\Chrome\Application\chrome.exe'),
os.path.expandvars(r'%LocalAppData%\Google\Chrome\Application\chrome.exe'),
]
for exe in candidates:
if exe and os.path.exists(exe):
out = run_cmd([exe, '--version'])
parsed = parse_version(out)
if parsed:
return exe, parsed
return None, None
def check_macos():
candidates = [
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
]
for exe in candidates:
if os.path.exists(exe):
out = run_cmd([exe, '--version'])
parsed = parse_version(out)
if parsed:
return exe, parsed
return None, None
def check_linux():
candidates = [
'google-chrome',
'google-chrome-stable',
'chromium',
'chromium-browser',
]
for cmd in candidates:
full = shutil.which(cmd)
if full:
out = run_cmd([full, '--version'])
parsed = parse_version(out)
if parsed:
return full, parsed
return None, None
def main():
system = platform.system().lower()
source = None
version = None
if 'windows' in system:
source, version = check_windows_registry()
if not version:
source, version = check_windows_files()
elif 'darwin' in system:
source, version = check_macos()
elif 'linux' in system:
source, version = check_linux()
else:
print('UNKNOWN - unsupported platform: {}'.format(platform.system()))
sys.exit(2)
if not version:
print('UNKNOWN - could not determine local Chrome version')
sys.exit(2)
if cmp_version(version, TARGET) < 0:
print('VULNERABLE - detected version {} via {}'.format('.'.join(map(str, version)), source))
sys.exit(1)
else:
print('PATCHED - detected version {} via {}'.format('.'.join(map(str, version)), source))
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
149.0.7827.53, make sure Chrome auto-update and relaunch enforcement are working, and fold stragglers into your normal desktop browser cleanup rather than preempting edge, identity, or server-side emergencies. For this LOW reassessment there is noisgate mitigation SLA: no SLA and noisgate remediation SLA: no SLA — treat as backlog hygiene, so the right move is routine version hygiene this month, not an out-of-band patch fire drill.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.