A peephole in the GPU fence that lets the neighbor read your mail, but only if you invite them onto the porch first
CVE-2026-11110 is an uninitialized-memory-use flaw in Chrome's ANGLE graphics abstraction layer (the WebGL backend). When a renderer invokes certain WebGL operations, ANGLE fails to zero-initialize GPU-allocated memory before re-use, leaving residual data from prior cross-origin rendering contexts readable via readPixels() or equivalent texture readback calls. The result is a Same-Origin Policy bypass: a crafted HTML page can silently exfiltrate fragments of pixel data, URLs, and metadata from other origins sharing the GPU process. All Chrome/Chromium versions prior to 149.0.7827.53 across Windows, macOS, and Linux are affected. Chromium-based browsers (Edge, Brave, Opera, Vivaldi) inherit the flaw until they rebase to the patched ANGLE commit.
Google's MEDIUM / 6.5 rating is honest and proportionate. The CVSS vector correctly captures the key dynamics: network-reachable (AV:N), no privileges needed (PR:N), but mandatory user interaction (UI:R), and impact limited to confidentiality (C:H / I:N / A:N). This is not RCE — there is no code execution, no sandbox escape, and no path to host compromise. The GPU process is itself sandboxed, and Chrome's Strict Site Isolation further constrains which cross-origin data actually co-resides in GPU memory. The 6.5 is arguably generous given the practical constraints; real-world severity is closer to 5.5 once auto-update cadence and exploitation difficulty are factored in.
4 steps from start to impact.
Victim visits attacker-controlled page
- Victim must actively navigate to attacker-controlled content
- Victim's browser must be Chrome < 149.0.7827.53
- Chrome auto-updates on restart; enterprise fleet exposure window is typically 3–7 days post-release
- Modern email gateways and URL-reputation services flag novel phishing domains
WebGL context triggers uninitialized ANGLE allocation
- Hardware acceleration must be enabled (default)
- Victim's GPU driver and platform must exercise the vulnerable ANGLE backend (Vulkan, Metal, or desktop GL)
- Some enterprise lockdown policies disable hardware acceleration, eliminating this path entirely
- Not all GPU driver/platform combinations reliably trigger the vulnerable code path
Stale GPU memory read back via readPixels
readPixels() or by rendering the texture to a canvas and calling toDataURL(). The returned data contains fragments of cross-origin rendered content — potentially including session tokens visible in URL bars, page content from other tabs, or internal application UI elements rendered through the GPU.- Cross-origin data of interest must have been recently rendered through the same GPU process
- Timing must align — the stale memory must not yet be overwritten by other GPU work
- Chrome's Strict Site Isolation means each site gets its own renderer process, limiting what data shares GPU memory space
- The leaked data is fragmented pixel data, not structured DOM — extracting actionable secrets requires significant post-processing
- Data is ephemeral; the attacker gets whatever happened to be in GPU memory, not targeted exfiltration
Cross-origin data exfiltrated to attacker server
fetch() or XMLHttpRequest. If the leaked fragments contain recognizable content (e.g., a rendered email body, an internal dashboard with PII), the attacker has achieved a Same-Origin Policy bypass. The attack can be repeated in a loop to harvest more data, though each read returns unpredictable fragments.- Outbound network access from the victim's browser to the attacker's collection endpoint
- Enterprise web proxies and DLP may flag unusual data exfiltration patterns from browser contexts
- The attacker cannot target specific data — extraction is opportunistic and noisy
BrowserMinimumVersion policy to block launch of older versions. This is the primary remediation and should be verified within the 365-day noisgate remediation SLA for MEDIUM — though in practice Chrome auto-update achieves this within days. No separate mitigation SLA applies for MEDIUM.HardwareAccelerationModeEnabled to false via GPO or MDM. This forces software rendering, completely eliminating the ANGLE attack surface. Performance impact is significant for WebGL-heavy workloads but acceptable for general enterprise browsing. Apply as a temporary control if auto-update is blocked or delayed in your environment.SitePerProcess Chrome policy is enabled (default since Chrome 67). For sensitive internal web applications, deploy Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Embedder-Policy: require-corp response headers. This further isolates cross-origin data in memory, reducing the probability that sensitive content co-resides with the attacker's GPU allocations.SafeBrowsingProtectionLevel policy set to 1 or 2) and that your Secure Web Gateway blocks uncategorized/newly-registered domains. This reduces the probability that a victim reaches the attacker's crafted page — the mandatory UI:R prerequisite.- Network-level IDS/IPS signatures — The exploit is standard WebGL JavaScript served over HTTPS. There is no network-layer indicator to signature; the malicious payload is indistinguishable from legitimate WebGL content at the packet level.
- Disabling JavaScript — While technically effective, this breaks virtually all modern web applications and is not a viable enterprise control.
- Content Security Policy (CSP) on the attacker's page — CSP is a server-side control. The attacker controls their own page's CSP and will not restrict themselves. CSP on *your* internal apps does not prevent the attacker's page from reading stale GPU memory.
The supporting signals.
| In-the-wild exploitation | None observed. Not listed on CISA KEV. Google's Chrome 149 release notes state no patched vulnerabilities were exploited in the wild. No GreyNoise or Shadowserver tags for this CVE. |
|---|---|
| Proof of concept | No public PoC found. No GitHub repos named after CVE-2026-11110. Not indexed on pocindex.io. No Nuclei templates, ExploitDB entries, or Metasploit modules. The KSEC Community Forum references an exploit feed entry but the page returns 403 — likely a placeholder, not a working PoC. |
| EPSS | 0.0025 (0.25%) — 16th percentile. Places this in the bottom quintile of exploitation probability, consistent with the lack of weaponization. |
| KEV status | Not listed. No CISA deadline applies. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N — Network-reachable, low complexity, no auth, but requires user interaction. Impact is confidentiality-only (High), no integrity or availability. Scope unchanged — the bug does not break out of the GPU sandbox. |
| Affected versions | All Google Chrome versions < 149.0.7827.53 across Windows, macOS, and Linux. Chromium-based browsers (Edge, Brave, Opera, Vivaldi) affected until they rebase ANGLE. Chromium-browser snap on Ubuntu marked 'not affected' because the snap auto-updates independently. |
| Fixed version | Chrome 149.0.7827.53 (Stable channel, released 2026-06-04). Distro backports: Ubuntu ships via snap auto-update; Debian tracks via chromium package. Edge typically follows within 1–2 weeks. |
| Scanning/exposure | No Shodan/Censys/FOFA exposure data applicable — this is a client-side browser vulnerability, not a server-side service. Enterprise exposure is measured by browser version compliance: any Chrome < 149 in fleet is exposed. Google CBCM or Intune browser inventory is the correct data source. |
| Disclosure timeline | Disclosed 2026-06-04 alongside Chrome 149 stable release. Chromium bug tracker: issues.chromium.org/issues/500528864 (access-restricted). Last NVD modification: 2026-07-23. |
| Reporting researcher | Not publicly credited in available release notes. Bounty amount not disclosed. Chrome 149 included 429 total fixes; the bulk of credited ANGLE researchers received between $5,000–$97,000 for higher-severity bugs in the same component. |
Sources.
Why this verdict
- Auto-update exposure window: Chrome's aggressive auto-update mechanism means the median enterprise fleet patches within 3–7 days of stable release. This CVE was disclosed 2026-06-04; by mid-June, the vast majority of managed Chrome installations had already updated. The practical window for exploitation is extremely narrow, compounding downward from the vendor's static 6.5.
- No weaponization pressure: EPSS is 0.25% (16th percentile), no PoC exists publicly, no exploitation in the wild, and no KEV listing. The attack requires crafting specific WebGL API call sequences to trigger the uninitialized ANGLE allocation — nontrivial exploit development with low ROI given the confidentiality-only payoff.
- User interaction gate: The victim must navigate to attacker-controlled content (
UI:R). This requires a successful phishing lure or watering-hole placement, both of which are filtered by modern email gateways, URL reputation, and Safe Browsing — each an independent friction layer. - Fragmented, opportunistic data leak: Unlike a structured API data exfiltration, the attacker gets raw pixel fragments from GPU memory. Extracting actionable secrets (session tokens, PII) from rendered pixel data requires significant post-processing and favorable timing. This is not equivalent to reading a cookie jar.
- Role multiplier: Chrome is a *client-side endpoint application*, not infrastructure. The blast radius of successful exploitation is confined to one user's browser session data — there is no path from this bug to host compromise, lateral movement, domain takeover, or fleet-scale impact. Chrome does not occupy any high-value infrastructure role (not a DC, hypervisor, CI/CD system, edge appliance, or identity provider). The floor analysis does not elevate the verdict.
- Site Isolation limits co-residency: Chrome's Strict Site Isolation places different origins in separate renderer processes. While the GPU process is shared, the cross-origin data available in GPU memory is limited to *rendered pixel output*, not DOM, cookies, or JavaScript state. This architecturally constrains the severity of any data leak.
Why not higher?
This is not HIGH because there is no code execution, no sandbox escape, and no path beyond the browser. The impact is confidentiality-only, limited to opportunistic pixel-data fragments rather than structured secrets. No exploitation exists in the wild, the EPSS is bottom-quintile, and Chrome's auto-update eliminates the exposure window before most attackers could develop a working exploit. The component (Chrome browser) does not occupy any high-value infrastructure role that would trigger a verdict floor.
Why not lower?
This is not LOW because the vulnerability does bypass the Same-Origin Policy — a fundamental web security boundary — without requiring any authentication. The CVSS C:H rating is justified: if an attacker *does* craft a working exploit and *does* get a victim to visit it during the brief pre-patch window, they can read GPU-resident cross-origin data from other tabs, potentially including sensitive internal application content. The attack complexity is genuinely low (AC:L), and the network attack vector means any internet user is reachable. The SOP bypass alone keeps this firmly in MEDIUM territory.
Crowdsourced verification payload.
Run on each Windows endpoint (or via SCCM/Intune script deployment) as any user. Invoke: powershell -ExecutionPolicy Bypass -File Check-CVE-2026-11110.ps1. No admin privileges required. Also works on macOS/Linux by checking the version from the Chrome binary path — but the PowerShell version covers the dominant enterprise case.
#!/usr/bin/env pwsh
# Check-CVE-2026-11110.ps1
# Checks whether installed Google Chrome is vulnerable to CVE-2026-11110
# (Uninitialized Use in ANGLE, fixed in 149.0.7827.53)
# Exit codes: 1 = VULNERABLE, 0 = PATCHED, 2 = UNKNOWN
$FixedVersion = [version]'149.0.7827.53'
function Get-ChromeVersion {
# Try registry first (HKLM for machine-wide, HKCU for per-user)
$regPaths = @(
'HKLM:\SOFTWARE\Google\Chrome\BLBeacon',
'HKLM:\SOFTWARE\WOW6432Node\Google\Chrome\BLBeacon',
'HKCU:\SOFTWARE\Google\Chrome\BLBeacon'
)
foreach ($p in $regPaths) {
try {
$v = (Get-ItemProperty -Path $p -Name 'version' -ErrorAction Stop).version
if ($v) { return $v }
} catch { }
}
# Fallback: check default install path
$exePath = "$env:ProgramFiles\Google\Chrome\Application\chrome.exe"
if (-not (Test-Path $exePath)) {
$exePath = "${env:ProgramFiles(x86)}\Google\Chrome\Application\chrome.exe"
}
if (Test-Path $exePath) {
return (Get-Item $exePath).VersionInfo.ProductVersion
}
return $null
}
$installedStr = Get-ChromeVersion
if (-not $installedStr) {
Write-Output 'UNKNOWN - Google Chrome not detected on this host.'
exit 2
}
try {
$installed = [version]$installedStr
} catch {
Write-Output "UNKNOWN - Could not parse Chrome version: $installedStr"
exit 2
}
if ($installed -lt $FixedVersion) {
Write-Output "VULNERABLE - Chrome $installedStr is below fixed version $FixedVersion (CVE-2026-11110)"
exit 1
} else {
Write-Output "PATCHED - Chrome $installedStr is at or above fixed version $FixedVersion"
exit 0
}