01 · The Real Story
Like finding a sticky note with a safe combination — but only after you've already broken into the building and are locked inside a glass booth
CVE-2026-11104 is an uninitialized memory read in ANGLE, Chrome's cross-platform graphics abstraction layer. When ANGLE allocates a buffer for GPU command processing without zeroing it first, stale data from previous allocations can be read back. An attacker who has already compromised the renderer process (i.e., already holds arbitrary code execution inside Chrome's sandbox via a *separate* vulnerability) can craft WebGL/ANGLE calls that return fragments of renderer process memory — heap pointers, ASLR base addresses, partial DOM data, or other in-process secrets. All Chrome versions prior to 149.0.7827.53 (stable released 2026-06-05) are affected across Windows, macOS, Linux, and ChromeOS. Debian backports are available as 149.0.7827.53-1~deb12u1 (Bookworm) and 149.0.7827.53-1~deb13u1 (Trixie).
Google's Chromium team rated this Medium (6.5), and the CVSS vector AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N overstates its real-world accessibility. The vector claims PR:N (no privileges required) and AC:L (low complexity), but the advisory's own description contradicts this: exploitation requires an attacker who has already compromised the renderer process. That prerequisite means a separate RCE vulnerability must be in play *first*. The CVSS does not model chained prerequisites, so the 6.5 score is an artifact of the scoring system's limitations, not a reflection of standalone risk. As a chain-only info-leak primitive inside a sandboxed process, the real-world severity is closer to LOW.
"A post-compromise info leak in a sandboxed renderer: useful for exploit chains, not for your patch sprint."
02 · The Attack Path
4 steps from start to impact.
STEP 01
Renderer process compromise
The attacker must first achieve arbitrary code execution inside Chrome's sandboxed renderer process. This requires a *separate* vulnerability — typically a V8 type confusion, a use-after-free in Blink, or a compromised extension with native code. Without this prerequisite, CVE-2026-11104 is completely unreachable. This step alone is a high-value, expensive capability.
Conditions required:
- A separate RCE vulnerability in the renderer (e.g., V8, Blink, or a malicious extension)
- User must visit attacker-controlled or attacker-compromised page
Where this breaks in practice:
- Renderer RCE bugs in Chrome are rare, expensive (~$250K+ on exploit markets), and short-lived due to auto-update
- Chrome's V8 sandbox (V8 Heap Sandbox / Memory Cage) introduced in 2024+ significantly raises the bar for V8-based renderer compromise
- Site Isolation ensures each origin gets its own renderer, limiting cross-origin chaining
Detection/coverage: EDR behavioral detection on anomalous child processes of chrome.exe/chrome. CrowdStrike Falcon, SentinelOne, and Microsoft Defender for Endpoint all flag renderer-level exploitation signals.
STEP 02
Craft malicious ANGLE calls
With code execution inside the renderer, the attacker constructs WebGL/ANGLE API calls that trigger allocation of GPU command buffers without proper initialization. The attacker controls the size and timing of allocations to maximize the chance of reading interesting stale data. This is a targeted heap-spray/feng-shui technique applied to ANGLE's internal allocator.
Conditions required:
- Active code execution in the renderer process
- WebGL/ANGLE enabled (default in all Chrome builds)
Where this breaks in practice:
- ANGLE's buffer allocation patterns vary by GPU driver and OS, making reliable info-leak across diverse hardware non-trivial
- Chrome's
--disable-webglflag or enterprise policyWebGlAllowed=falseblocks this path entirely
Detection/coverage: No standard scanner detects this step. Chrome's internal crash reporting (Breakpad/Crashpad) may capture anomalous ANGLE faults.
STEP 03
Read uninitialized memory
The crafted ANGLE calls return buffer contents that include stale data from previous allocations within the renderer's address space. The attacker parses the returned data looking for useful primitives: heap addresses (to defeat ASLR), vtable pointers (to build ROP chains), or partial content from previously rendered pages.
Conditions required:
- Successful triggering of uninitialized buffer read via ANGLE
- Renderer process has useful secrets in its heap at the time of the read
Where this breaks in practice:
- The renderer is sandboxed — the process memory does not contain OS credentials, cookies (stored in the browser process), or filesystem data
- Leaked pointers are only useful for further exploitation within the same process or for a sandbox escape chain, which requires yet another vulnerability
- ASLR re-randomizes on process restart, and Chrome regularly recycles renderer processes
STEP 04
Chain into sandbox escape (hypothetical)
The attacker uses leaked ASLR bases or heap layout information to reliably exploit a *third* vulnerability — a sandbox escape bug — that would otherwise be blocked by address-space randomization. This converts a probabilistic exploit into a deterministic one. This step requires a separate sandbox escape vulnerability that the attacker already possesses but cannot reliably trigger without the info leak.
Conditions required:
- A separate sandbox escape vulnerability
- Leaked addresses remain valid (no renderer restart)
- Attacker has the engineering skill to chain three bugs reliably
Where this breaks in practice:
- Full Chrome exploit chains (renderer RCE + info leak + sandbox escape) are nation-state grade and trade at $1M+ on the open market
- Chrome's sandbox on Windows uses Arbitrary Code Guard (ACG) and Code Integrity Guard (CIG), making even post-leak exploitation extremely difficult
- Auto-update closes the window within 24-72 hours for most of the Chrome population
Detection/coverage: Sandbox escape triggers observable kernel/OS-level signals. EDR products detect process creation, handle duplication, and token manipulation from sandboxed renderer children. Google's MiraclePtr and PartitionAlloc hardening generate crash reports on use-after-free attempts.
03 · Compensating Control
1
LOW 3.0→IGNORE 0.0
SEVERITY REDUCEDEnforce Chrome auto-update and verify fleet version ≥ 149.0.7827.53 — Chrome's built-in updater should have already deployed the fix. Use your endpoint management platform (Intune, SCCM, Tanium, Qualys) to verify no stragglers remain below 149.0.7827.53. As a LOW-severity finding, there is no noisgate mitigation SLA — treat this as backlog hygiene and verify during your next scheduled compliance scan.
2
LOW 3.0→IGNORE 0.0
SEVERITY REDUCEDDisable WebGL via enterprise policy for sensitive roles — Set the Chrome enterprise policy
WebGlAllowed to false (or launch with --disable-webgl) on kiosk machines, privileged access workstations (PAWs), or other sensitive endpoints. This kills the ANGLE attack surface entirely. Acceptable for admin workstations; likely breaks line-of-business web apps that use 3D rendering.3
LOW 3.0→IGNORE 0.0
SEVERITY REDUCEDDeploy browser isolation for high-risk browsing — Tools like Menlo Security, Zscaler Browser Isolation, or Cloudflare RBI render web content in a remote container, so even a full renderer compromise occurs on disposable infrastructure — not the endpoint. This neutralizes the entire chain this bug participates in.
What doesn't work
- Network-level blocking (WAF, firewall, IDS) — This is a client-side browser vulnerability triggered by rendering a webpage. There is no network signature to block; the malicious ANGLE calls happen inside the browser process, not over the wire.
- Disabling JavaScript — While this would prevent many renderer RCE bugs (Step 1), it does not directly prevent ANGLE uninitialized reads if the renderer is compromised by other means (e.g., a malicious extension with native code). It also breaks virtually all modern web applications.
- Content Security Policy (CSP) headers — CSP controls script sources on your own sites but has zero effect on what happens when a user visits an attacker-controlled page. The vulnerability is in the browser, not in your web application.
04 · Intelligence Metadata
The supporting signals.
| In-the-Wild Exploitation | None observed. Not listed in CISA KEV. No reports from Google TAG, Mandiant, or MSTIC. No GreyNoise/Shodan scanning activity (client-side vuln, not server-scannable). |
|---|---|
| Proof-of-Concept | No public PoC found. Checked pocindex.io, GitHub (no repo named CVE-2026-11104), ExploitDB, and Nuclei templates — all negative. The Chromium bug tracker issue #500501226 is access-restricted per standard Chromium disclosure policy. |
| EPSS | 0.0025 (0.25%), 16th percentile. Bottom quintile — the model sees near-zero probability of exploitation in the next 30 days. |
| KEV Status | Not listed. No CISA Known Exploited Vulnerabilities entry as of 2026-09-30. |
| CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N — 6.5 Medium. The PR:N metric is misleading: the advisory explicitly requires prior renderer compromise. A more honest encoding would use PR:H or AC:H, which would drop the score to ~4.2-5.3. |
| Affected Versions | All Google Chrome / Chromium versions prior to 149.0.7827.53 (effectively Chrome 113 through 148.x). Edge, Brave, Opera, and other Chromium-based browsers with ANGLE are also affected until they rebase. |
| Fixed Versions | Chrome 149.0.7827.53 (Linux), 149.0.7827.53/54 (Windows/macOS), released 2026-06-05. Debian: 149.0.7827.53-1~deb12u1 (Bookworm), 149.0.7827.53-1~deb13u1 (Trixie), 149.0.7827.53-1 (Sid). |
| Scanning / Exposure | Not applicable — this is a client-side browser vulnerability. No Shodan/Censys/FOFA exposure surface. Enterprise visibility depends on software inventory (SCCM, Intune, Tanium, Qualys Agent) reporting Chrome version. |
| Disclosure Date | 2026-06-04 (NVD published). Chrome 149 stable released 2026-06-05. |
| Reporter | Not publicly credited. Chromium bug #500501226 is restricted. No external researcher named in the Chrome 149 release notes for this specific CVE. |
Sources.
05 · The Call
Final Verdict
↓ DOWNGRADED to LOW (3.0/10)
Why this verdict
- Renderer compromise prerequisite is a showstopper. The CVSS vector scores this as
PR:N/AC:L, but the advisory itself says the attacker must have *already compromised the renderer process*. That requires a separate, high-value RCE vulnerability. This single prerequisite transforms the bug from 'network-reachable info-leak' to 'post-exploitation chain primitive,' collapsing the real-world attack surface by orders of magnitude. - Information disclosure only, inside a sandbox. Even when triggered, the bug leaks stale heap data from the *sandboxed renderer process* — not from the browser process (which holds cookies, passwords, autofill) or the OS. The leaked data (heap pointers, ASLR bases) is only useful for further exploitation, which requires *yet another* vulnerability. No standalone confidentiality harm to the user.
- Chrome auto-update eliminates the exposure window. Google's auto-update mechanism pushes stable patches to >90% of the Chrome population within 72 hours. By the time an attacker could develop and weaponize a chain incorporating this info leak, the target population has already moved past 149.0.7827.53.
- No PoC, no exploitation, rock-bottom EPSS. Zero public proof-of-concept code, zero in-the-wild exploitation, not on KEV, EPSS at 0.25% (16th percentile). There is no evidence that anyone outside Google's internal security team has reproduced this bug.
- Role multiplier: Chrome is a *workstation client application*. It does not occupy any high-value deployment role (not a domain controller, hypervisor, CI/CD system, network edge appliance, or identity provider). The worst-case blast radius is a single user's sandboxed browsing tab on a single endpoint. Even if chained into a full exploit, the outcome is single-host compromise of a workstation — not domain takeover, fleet compromise, or supply-chain pivot. No high-value role floor applies.
Why not higher?
A MEDIUM rating would require the bug to be exploitable without a separate prerequisite vulnerability, or to produce meaningful standalone impact. Neither is true. The info leak delivers no user-visible harm on its own — no data exfiltration, no code execution, no persistence. The CVSS vector's PR:N is factually contradicted by the advisory text, and accepting it at face value would overcount the risk. The lack of any PoC or wild exploitation after nearly four months further erodes the case for MEDIUM.
Why not lower?
An IGNORE rating would require the bug to be entirely theoretical or affect dead/deprecated code. ANGLE is live, default-enabled code in every Chrome build, and the info leak *is* real — it could serve as a reliable ASLR bypass primitive in a nation-state exploit chain. The bug has non-zero value to sophisticated adversaries even if it has zero value as a standalone threat. That residual chain utility keeps it at LOW rather than IGNORE.
06 · Verification
Crowdsourced verification payload.
Run this on each target host (or pull Chrome version data from your fleet management tool). Requires read access to the Chrome binary — no elevated privileges needed. Example: bash check_cve_2026_11104.sh or pipe into your fleet scanner.
#!/usr/bin/env bash
# check_cve_2026_11104.sh
# Checks if installed Google Chrome / Chromium is vulnerable to CVE-2026-11104
# (Uninitialized Use in ANGLE, fixed in 149.0.7827.53)
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN
set -euo pipefail
FIXED_MAJOR=149
FIXED_MINOR=0
FIXED_BUILD=7827
FIXED_PATCH=53
get_chrome_version() {
local bin=""
for candidate in google-chrome google-chrome-stable chromium-browser chromium \
/opt/google/chrome/google-chrome \
"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"; do
if command -v "$candidate" &>/dev/null || [ -x "$candidate" ]; then
bin="$candidate"
break
fi
done
if [ -z "$bin" ]; then
echo ""
return
fi
"$bin" --version 2>/dev/null | grep -oE '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+' | head -1
}
version_gte() {
# Returns 0 if $1 >= fixed version
IFS='.' read -r maj min bld pat <<< "$1"
if (( maj > FIXED_MAJOR )); then return 0; fi
if (( maj < FIXED_MAJOR )); then return 1; fi
if (( min > FIXED_MINOR )); then return 0; fi
if (( min < FIXED_MINOR )); then return 1; fi
if (( bld > FIXED_BUILD )); then return 0; fi
if (( bld < FIXED_BUILD )); then return 1; fi
if (( pat >= FIXED_PATCH )); then return 0; fi
return 1
}
VERSION=$(get_chrome_version)
if [ -z "$VERSION" ]; then
echo "UNKNOWN — Chrome/Chromium not found on this host."
exit 2
fi
echo "Detected Chrome version: $VERSION"
echo "Fixed version: $FIXED_MAJOR.$FIXED_MINOR.$FIXED_BUILD.$FIXED_PATCH"
if version_gte "$VERSION"; then
echo "PATCHED — Chrome $VERSION is >= $FIXED_MAJOR.$FIXED_MINOR.$FIXED_BUILD.$FIXED_PATCH. CVE-2026-11104 is remediated."
exit 0
else
echo "VULNERABLE — Chrome $VERSION is below $FIXED_MAJOR.$FIXED_MINOR.$FIXED_BUILD.$FIXED_PATCH. CVE-2026-11104 applies."
exit 1
fi