CVE-2026-11109 · Uninitialized Use in ANGLE Leaks Cross-Origin Data in Chrome

01 · The Real Story

Someone left a whiteboard un-erased in a glass office — you can read fragments if you press your face to the window

CVE-2026-11109 is an uninitialized-memory-read bug in ANGLE, the graphics abstraction layer Chrome uses for WebGL and GPU-accelerated rendering. When a crafted HTML page triggers specific WebGL API calls, ANGLE hands back a buffer it never zeroed out. That buffer can contain pixel data, texture fragments, or other GPU-resident content belonging to *other origins* — violating the same-origin policy. Affected versions: all Google Chrome builds prior to 149.0.7827.53 on Windows, macOS, and Linux. The fix shipped June 4, 2026, as part of Chrome 149's record 429-vulnerability mega-patch.

Google's MEDIUM / 6.5 rating is broadly fair but arguably generous for the *practical* threat. The CVSS vector (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N) gives full marks to confidentiality impact, yet what actually leaks is uninitialized *GPU* memory — not arbitrary process memory, not cookies, not tokens in RAM. You get stale texture data and framebuffer fragments: enough for a pixel-stealing academic paper, but far from a reliable credential-harvesting chain. There is no code execution, no integrity impact, and no availability impact. The Chrome sandbox further bounds the renderer process. With no public PoC, no in-the-wild exploitation, and Chrome's aggressive auto-update cadence closing the window within days for most endpoints, the real-world risk sits below where the CVSS number lands.

"GPU memory scraps behind a click — annoying, not catastrophic."

02 · The Attack Path

4 steps from start to impact.

STEP 01

Victim visits attacker-controlled page

The attacker hosts or injects a page containing crafted WebGL content. This can be delivered via phishing email, malvertising, watering-hole compromise, or an ad network. The victim must actively navigate to or be redirected to the page in a vulnerable Chrome build.

Conditions required:

Victim running Chrome < 149.0.7827.53
Victim clicks a link or loads a page (UI:R)

Where this breaks in practice:

Chrome auto-updates within 24-72 hours for most consumer and managed-browser deployments
Enterprise deployments using Chrome Browser Cloud Management can force-update fleetwide

Detection/coverage: Email gateway URL scanning, web proxy categorization, Chrome SafeBrowsing

STEP 02

WebGL shader triggers uninitialized ANGLE buffer

The crafted page issues a sequence of WebGL API calls — likely involving texture allocation, framebuffer operations, or shader compilation — that cause ANGLE to allocate a GPU-side buffer without initializing it. The specific call sequence exploits a code path where memset or equivalent zeroing was omitted. No known public PoC or weaponized tool exists for this step.

Conditions required:

WebGL enabled in the browser (default on)
Hardware acceleration enabled (default on)

Where this breaks in practice:

Enterprises that disable WebGL via policy (WebGLAllowed = false) are immune
Software-rendering fallback (SwiftShader) may not hit the same code path
The exact trigger sequence is undisclosed — Chromium bug #500524833 is still access-restricted

STEP 03

Stale GPU memory read back to renderer

ANGLE returns the uninitialized buffer contents to the Chrome renderer process via readPixels or an equivalent readback path. The buffer may contain pixel data, texture fragments, or partial framebuffer content from previously rendered origins. The attacker's JavaScript reads this data from a canvas or WebGL context.

Conditions required:

The GPU previously rendered content from a different origin in the same process/GPU context

Where this breaks in practice:

Chrome's site-isolation (one renderer per site) limits which origins share GPU context
The data recovered is raw pixel fragments — not structured text, cookies, or tokens
Data quality is nondeterministic: the attacker cannot choose *which* memory to read

STEP 04

Cross-origin data exfiltrated

The attacker's JavaScript encodes the leaked pixel data and sends it to a collection endpoint. The actual intelligence value depends entirely on what the GPU happened to have cached — it could be a fragment of a banking page, a blank buffer, or a UI widget sprite. There is no way to target specific secrets.

Conditions required:

Leaked buffer contains recognizable cross-origin content

Where this breaks in practice:

Exfiltration is visible to DLP/proxy inspection
Leaked data is probabilistic and low-fidelity — this is not a reliable data-theft primitive

Detection/coverage: Outbound DLP, network proxy logging for unusual canvas/WebGL readback exfiltration patterns

03 · Compensating Control

MEDIUM 5.5→IGNORE 0.0

SEVERITY REDUCED

Force Chrome auto-update to ≥ 149.0.7827.53 via CBCM or MDM — The definitive fix is the vendor patch. Use Chrome Browser Cloud Management, Intune, SCCM, or your MDM of choice to enforce minimum version 149.0.7827.53 across the fleet. Block launch of older versions via BrowserVersionMinimum policy. Per the noisgate remediation SLA for MEDIUM, complete fleet-wide rollout within 365 days — though Chrome's auto-update should have already handled this for most endpoints in the ~4 months since disclosure.

MEDIUM 5.5→IGNORE 0.0

SEVERITY REDUCED

Disable WebGL via Chrome enterprise policy — Set WebGLAllowed to false in Chrome enterprise policy to completely eliminate the ANGLE attack surface. This breaks WebGL-dependent web apps (3D visualization, mapping, some dashboards), so evaluate business impact before deploying. This is a targeted control if you cannot patch specific endpoints. No noisgate mitigation SLA applies to MEDIUM — go straight to the 365-day remediation window.

MEDIUM 5.5→LOW 2.0

SEVERITY REDUCED

Disable hardware acceleration as a fallback — Setting HardwareAccelerationModeEnabled to false forces Chrome into software rendering, which may bypass the vulnerable ANGLE GPU code path. Performance will degrade significantly for graphics-heavy pages. Use this only for high-sensitivity endpoints (finance, exec, admin workstations) where WebGL must remain enabled but the ANGLE risk is unacceptable.

What doesn't work

Network-level blocking (WAF/IPS): This is a client-side browser bug triggered by JavaScript in the victim's renderer. There is no network signature to match — the malicious WebGL calls happen entirely inside the browser process. A WAF protects servers, not browser internals.
Content Security Policy (CSP): CSP on your own sites won't help because the attack page is hosted on the *attacker's* origin. CSP on the attacker's page is controlled by the attacker.
EDR/endpoint detection: No known behavioral signature exists for this vuln. EDR agents don't inspect WebGL API call sequences inside the Chrome renderer sandbox. This is a read-only information disclosure, not a file/process/registry operation that EDR would flag.

04 · Intelligence Metadata

The supporting signals.

In-the-wild exploitation	None observed. Not in CISA KEV. Google's Chrome 149 release notes state none of the 429 patched vulnerabilities were exploited in the wild at time of disclosure.
Proof-of-concept	No public PoC found. Checked pocindex.io (404 — no entry), GitHub (`site:github.com CVE-2026-11109` — no repos), ExploitDB, and nuclei templates. The Chromium bug (issues.chromium.org/500524833) remains access-restricted.
EPSS	0.25% (16th percentile) — bottom quintile. The model sees near-zero exploitation probability in the next 30 days.
KEV status	Not listed. No CISA binding operational directive deadline applies.
CVSS vector	`CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N` — network-accessible, no auth, but requires a click. Confidentiality-only impact; no integrity or availability. Scope unchanged means no sandbox escape.
Affected versions	Google Chrome < 149.0.7827.53 on Windows, macOS, and Linux. Chromium-based browsers (Edge, Brave, Opera, Vivaldi) sharing the same ANGLE version are also affected. Ubuntu marks `chromium-browser` as not affected across 22.04–26.04 (snap-based builds were already updated).
Fixed versions	Chrome 149.0.7827.53 (stable, June 4 2026). Microsoft Edge, Brave, and other Chromium downstream forks shipped aligned patches within 1–2 weeks.
Scanning / exposure	Not applicable for Shodan/Censys/GreyNoise — this is a client-side browser vulnerability, not an exposed service. Nessus plugin coverage expected via Tenable's Chrome version-check family. Qualys QID likely published within days of disclosure.
Disclosure date	2026-06-04 (Chrome 149 stable release). Last NVD update: 2026-07-23.
Reporting researcher	Not publicly credited in the Chrome 149 release notes or available advisory text. Bug bounty amount for this specific CVE is undisclosed (the $97K bounty went to CVE-2026-10881, a critical ANGLE OOB R/W).

Sources.

05 · The Call

Final Verdict

= UNCHANGED to MEDIUM (5.5/10)

Why this verdict

No PoC, no exploitation, bottom-quintile EPSS: With 0.25% EPSS, no public exploit code, no KEV listing, and Google confirming zero in-the-wild exploitation at disclosure, the practical threat is theoretical. An attacker would need to independently develop a trigger for the specific uninitialized ANGLE code path — a non-trivial reverse-engineering effort against a now-patched codebase.
Chrome auto-update compresses the exposure window: Chrome's background updater means the median consumer endpoint patches within 72 hours. Enterprise Chrome fleets using CBCM or Intune typically enforce updates within 7–14 days. By today (nearly 4 months post-patch), the residual vulnerable population is negligible outside locked-down kiosks or abandoned installs.
Leaked data is GPU pixel fragments, not structured secrets: The C:H in the CVSS vector overstates the real-world confidentiality impact. What leaks is uninitialized GPU memory — stale texture data and framebuffer fragments — not cookies, tokens, or process memory. The attacker cannot target specific data. This is a probabilistic pixel-scraping primitive, not a credential-theft vector.
User interaction required and Chrome sandbox intact: The attack requires the victim to visit a malicious page (UI:R). The scope is Unchanged — no sandbox escape — so the renderer process boundary holds. Site isolation further limits which origins share GPU context.
Role multiplier: Chrome is a client-side application. It does not occupy any canonical high-value server role (not a DC, IdP, hypervisor, CI/CD, backup, database, or network edge). The blast radius is per-user, per-session — one victim's stale pixel fragments. Even in the worst case (user has a sensitive banking/admin page open in another tab), the attacker gets random pixel noise, not a session token. No fleet-scale, domain-scale, or supply-chain outcome is reachable from this vulnerability alone. The high-value-role floor does not apply, and MEDIUM is not floored upward.

Why not higher?

There is no code execution, no sandbox escape, no integrity or availability impact, and no pathway from this bug alone to lateral movement, privilege escalation, or fleet compromise. The leaked data is nondeterministic GPU fragments — not actionable credentials. Elevating to HIGH would require either active exploitation evidence or a demonstrated chain to meaningful data exfiltration, neither of which exists.

Why not lower?

The attack surface is unauthenticated and network-reachable with only a click required. Chrome's installed base is enormous — billions of endpoints. If a reliable PoC emerged and were weaponized via malvertising, the *potential* reach would be significant even though the *impact per victim* is limited. A LOW rating would understate the ease of initial access and the sheer scale of the vulnerable population.

06 · Verification

Crowdsourced verification payload.

Run on each target Windows host where Chrome is installed. Execute from an elevated or standard PowerShell prompt: powershell -ExecutionPolicy Bypass -File .\Check-CVE-2026-11109.ps1. No admin privileges required — the script reads Chrome's version from the filesystem and registry.

noisgate-verify.ps1

POWERSHELLREAD-ONLYSAFE

#!/usr/bin/env pwsh
# Check-CVE-2026-11109.ps1
# Checks whether installed Google Chrome is vulnerable to CVE-2026-11109
# (Uninitialized Use in ANGLE < 149.0.7827.53)
# Exit codes: 1 = VULNERABLE, 0 = PATCHED, 2 = UNKNOWN

$FixedVersion = [version]'149.0.7827.53'
$ChromePaths = @(
    "$env:ProgramFiles\Google\Chrome\Application\chrome.exe",
    "${env:ProgramFiles(x86)}\Google\Chrome\Application\chrome.exe",
    "$env:LOCALAPPDATA\Google\Chrome\Application\chrome.exe"
)

$Found = $false
$Vulnerable = $false

foreach ($path in $ChromePaths) {
    if (Test-Path $path) {
        $Found = $true
        $verInfo = (Get-Item $path).VersionInfo
        $installed = [version]$verInfo.ProductVersion
        Write-Host "[*] Found Chrome at: $path"
        Write-Host "[*] Installed version: $installed"
        Write-Host "[*] Fixed version:     $FixedVersion"
        if ($installed -lt $FixedVersion) {
            Write-Host "[!] VULNERABLE — Chrome $installed is below the fix ($FixedVersion)."
            $Vulnerable = $true
        } else {
            Write-Host "[+] PATCHED — Chrome $installed meets or exceeds $FixedVersion."
        }
        break
    }
}

if (-not $Found) {
    # Try registry as fallback
    $regPaths = @(
        'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe',
        'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe'
    )
    foreach ($rp in $regPaths) {
        if (Test-Path $rp) {
            $exePath = (Get-ItemProperty $rp).'(Default)'
            if ($exePath -and (Test-Path $exePath)) {
                $Found = $true
                $verInfo = (Get-Item $exePath).VersionInfo
                $installed = [version]$verInfo.ProductVersion
                Write-Host "[*] Found Chrome via registry: $exePath"
                Write-Host "[*] Installed version: $installed"
                if ($installed -lt $FixedVersion) {
                    Write-Host "[!] VULNERABLE"
                    $Vulnerable = $true
                } else {
                    Write-Host "[+] PATCHED"
                }
                break
            }
        }
    }
}

if (-not $Found) {
    Write-Host "[?] UNKNOWN — Google Chrome not found on this host."
    exit 2
}

if ($Vulnerable) { exit 1 } else { exit 0 }