CVE-2026-11113 · Chrome ANGLE Insufficient Input Validation Sandbox Escape

01 · The Real Story

A locked second door that only matters after you've already broken through the first one

CVE-2026-11113 is an insufficient-input-validation flaw in ANGLE (Almost Native Graphics Layer Engine), the graphics abstraction layer Chrome uses to translate OpenGL ES calls into platform-native GPU APIs (Direct3D, Vulkan, Metal). The bug resides in the GPU process, which runs with elevated privileges relative to the sandboxed renderer. Exploiting it requires a remote attacker to first compromise the renderer process via a separate vulnerability, then send crafted IPC messages to ANGLE to escape the Chrome sandbox entirely and execute arbitrary code on the host OS. All desktop Chrome versions prior to 149.0.7827.53 (Windows, macOS, Linux) are affected. Chromium-based browsers (Edge, Brave, Opera, Vivaldi) shipping the same ANGLE revision are equally exposed until they rebase.

The vendor CVSS of 9.6 Critical (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H) is a textbook example of CVSS inflation for browser sandbox-escape bugs. The vector encodes PR:N (no privileges required) and AC:L (low attack complexity), but in reality the attacker needs a *separate, high-value renderer RCE* before this bug becomes reachable — a prerequisite CVSS simply cannot model. Chromium's own security team rated this bug Medium (S2), not High or Critical, per their severity guidelines — a guideline framework that explicitly rates sandbox escapes from compromised renderers at S1 (High) when reliably exploitable. The Medium rating signals additional limitations: likely constrained memory corruption, hardware-dependent exploitability, or low reliability. The 9.6 score overstates real-world risk by roughly 3 points.

"CVSS 9.6 hides a two-bug chain; Chromium rates it Medium. Downgraded to HIGH 6.8."

02 · The Attack Path

4 steps from start to impact.

STEP 01

Lure victim to attacker-controlled page

The attacker hosts or injects a malicious HTML page containing WebGL content crafted to trigger the ANGLE bug. The victim must navigate to this page via phishing, malvertising, watering-hole, or a redirect chain. No server-side exploitation is involved — the attack is entirely client-side over HTTPS.

Conditions required:

Victim uses Chrome < 149.0.7827.53 on desktop
Victim navigates to or is redirected to attacker-controlled content

Where this breaks in practice:

Chrome auto-update delivers patches within 24-72 hours of stable release — the vulnerable population shrinks rapidly
Enterprise Chrome policies may restrict navigation to known-bad domains
Email gateways and URL-rewriting proxies (Proofpoint, Mimecast, Zscaler) inspect links before delivery

Detection/coverage: URL reputation engines (Google Safe Browsing, SmartScreen) flag known malicious pages. EDR agents with browser telemetry (CrowdStrike, SentinelOne, Microsoft Defender for Endpoint) log suspicious navigations.

STEP 02

Exploit a separate renderer RCE

Before CVE-2026-11113 becomes reachable, the attacker must achieve code execution *inside* the renderer sandbox. This requires a distinct vulnerability — typically a V8 JIT bug, a Blink use-after-free, or a WebAssembly memory-safety flaw. High-quality renderer RCEs are rare, expensive, and actively hunted by Google's Project Zero and Chrome VRP. This step is the hard gate in the chain.

Conditions required:

Attacker possesses a working renderer-compromise exploit (separate CVE)
JavaScript execution is enabled in the victim's browser

Where this breaks in practice:

V8 sandbox (launched 2024) significantly raises the bar for JS engine exploitation
Site Isolation confines renderer processes per-origin, limiting cross-site data access even after compromise
MiraclePtr and PartitionAlloc hardening mitigate many UAF primitives in Blink
Chrome's Component Function-Level ASLR and Control Flow Integrity (CFI) break generic exploitation techniques

Detection/coverage: V8 sandbox violations trigger crash reports to Google. EDR products with user-mode hooking and JIT-spray detection (e.g., CrowdStrike Falcon, Microsoft Defender Exploit Guard) can flag anomalous renderer behavior.

STEP 03

Trigger ANGLE input-validation flaw via IPC

From the compromised renderer, the attacker crafts malicious IPC messages targeting the ANGLE component in the GPU process. The insufficient validation in ANGLE allows attacker-controlled data to reach a memory-corruption primitive. The GPU process runs outside the renderer sandbox and holds broader system access, making it a valuable pivot point.

Conditions required:

Renderer process is fully compromised (Step 2 complete)
ANGLE is active (WebGL or hardware-accelerated rendering enabled — the default)

Where this breaks in practice:

Chromium's Medium severity rating suggests the corruption is constrained — possibly requiring specific GPU hardware/drivers or yielding limited control
GPU process has its own (weaker) sandbox on Windows and macOS, adding a secondary barrier
Chrome's --disable-gpu flag eliminates the attack surface entirely, though it degrades rendering performance

Detection/coverage: GPU process crashes correlated with renderer compromise are logged by Chrome's crash reporter. Anomalous GPU-process IPC patterns may be visible to endpoint telemetry agents.

STEP 04

Escape Chrome sandbox

Successful exploitation of the ANGLE bug escalates the attacker from the GPU process into the host OS context, bypassing Chrome's sandbox boundary. The attacker now has code execution with the privileges of the Chrome browser process — typically the logged-in user's privileges. From here, standard post-exploitation (credential harvesting, lateral movement, persistence) applies.

Conditions required:

ANGLE memory corruption yields a reliable exploitation primitive
Host OS does not have additional exploit mitigations (e.g., Windows Exploit Guard ASR rules, macOS SIP) that block the specific technique

Where this breaks in practice:

The 'potentially' qualifier in the advisory language suggests the sandbox escape is not guaranteed — reliability is uncertain
Windows Defender Exploit Guard and macOS SIP provide defense-in-depth against sandbox escapes
Code execution occurs at user-level, not SYSTEM/root — privilege escalation would require yet another bug

Detection/coverage: EDR agents detect sandbox escape behavior patterns: unexpected child processes spawned by chrome.exe/Google Chrome, anomalous file-system or registry access, credential-store access. AMSI (Windows) and Endpoint Security Framework (macOS) provide kernel-level visibility.

03 · Compensating Control

HIGH 6.8→LOW 2.0

SEVERITY REDUCED

Enforce Chrome auto-update with maximum 72-hour rollout — Configure GoogleUpdate (Windows) or MDM policies (macOS/Linux) to enforce Chrome auto-update with a maximum 72-hour deferral window. Chrome 149.0.7827.53 was released on 2026-06-04 — nearly four months ago. Any endpoint still running a version below 149 has a systemic update failure that exposes it to this and hundreds of other patched vulnerabilities. Per the noisgate mitigation SLA for HIGH, deploy within 30 days — but since the patch has been available for months, this should be treated as an overdue hygiene action.

HIGH 6.8→IGNORE 0.0

SEVERITY REDUCED

Disable WebGL on high-value user profiles via Chrome policy — Set the Chrome enterprise policy WebGLAllowed to false for high-risk user populations (IT admins, executives, finance). This eliminates the ANGLE attack surface entirely by preventing WebGL content from initializing the GPU process's ANGLE layer. The tradeoff is degraded rendering for WebGL-heavy applications (3D visualization, CAD web apps, some mapping tools). Deploy within 30 days per the noisgate mitigation SLA for HIGH.

HIGH 6.8→MEDIUM 5.5

SEVERITY REDUCED

Deploy EDR with browser exploitation detection — Ensure EDR agents (CrowdStrike Falcon, Microsoft Defender for Endpoint, SentinelOne) are deployed on all endpoints with browser-process monitoring enabled. Modern EDR detects sandbox escape indicators: anomalous child processes from chrome.exe, GPU process crashes followed by suspicious system calls, credential-store access from browser context. This doesn't prevent exploitation but dramatically reduces dwell time and enables rapid containment. Deploy within 30 days per the noisgate mitigation SLA for HIGH.

HIGH 6.8→MEDIUM 5.0

SEVERITY REDUCED

Enable Windows Exploit Guard ASR rules for Office and browser processes — On Windows endpoints, enable Attack Surface Reduction (ASR) rules that block child process creation from browser processes and prevent credential theft from LSASS. Rules d4f940ab-401b-4efc-aadc-ad5f3c50688a (block child processes) and 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2 (block credential stealing) directly impede post-sandbox-escape activity. Deploy within 30 days per the noisgate mitigation SLA for HIGH.

What doesn't work

Network firewalls / IPS alone — the attack arrives over standard HTTPS (port 443) to the victim's browser. There is no network-level signature to block because the malicious payload is rendered client-side inside the browser process. TLS inspection would need to be paired with content inspection, and even then, obfuscated WebGL shaders evade static signatures.
Web Application Firewall (WAF) — WAFs protect server-side applications, not client-side browser components. The vulnerable ANGLE code runs on the victim's endpoint, not on a web server the defender controls.
Disabling JavaScript — while this would prevent many renderer-compromise vectors (Step 2), it breaks virtually all modern web applications and is not a viable enterprise control. Chrome's --disable-javascript flag is a non-starter for production use.
Content Security Policy (CSP) headers on your own sites — CSP only governs content loaded on domains you control. The attacker hosts their exploit on *their* domain, where they set their own CSP (or none). CSP on your corporate web properties does not protect your users when they browse elsewhere.

04 · Intelligence Metadata

The supporting signals.

In-the-Wild Exploitation	No evidence. Not listed in CISA KEV. No known campaigns. Google's advisory does not include the 'exploited in the wild' tag that accompanies actively exploited Chrome bugs (contrast with CVE-2024-7971, CVE-2025-2783).
Proof-of-Concept Availability	None found. No public PoC on GitHub, ExploitDB, or pocindex.io. No nuclei templates. No named researcher disclosure beyond the Chrome VRP report. The Chromium issue tracker entry (issues.chromium.org/issues/500560764) is access-restricted per standard Chromium 90-day disclosure policy.
EPSS Score	0.00265 (0.27%) — 18th percentile. Well below the 6% threshold that typically correlates with active exploitation campaigns. Indicates very low predicted exploitation probability.
CISA KEV Status	Not listed. No federal mandate to patch under BOD 22-01.
CVSS Vector Interpretation	`CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H` — Scope Changed (S:C) inflates the score because sandbox escape crosses a security boundary. However, `PR:N` is misleading: the attacker effectively needs a separate renderer RCE (equivalent to high privileges in practice). A more honest encoding would use `AC:H` and reduce the score to ~7.5.
Vendor Severity Discrepancy	NVD/CVSS: Critical 9.6 vs. Chromium: Medium (S2). Chromium's own guidelines rate reliable sandbox escapes from compromised renderers at High (S1). The Medium rating implies additional exploitability constraints — likely unreliable corruption, hardware dependence, or limited control.
Affected Version Range	All Google Chrome desktop versions < 149.0.7827.53 (Windows, macOS, Linux). Chromium-based browsers (Edge, Brave, Opera, Vivaldi) sharing the same ANGLE revision are affected until they ship their own rebased update.
Fixed Versions	Chrome ≥ 149.0.7827.53 (stable, released 2026-06-04). Debian: patched via DSA-6325-1 (chromium package). Ubuntu: chromium-browser snap auto-updates; marked 'not affected' across 22.04–26.04 LTS.
Scanning / Exposure Data	Not applicable for GreyNoise/Shodan/Censys — this is a client-side browser vulnerability, not a server-side service. Exposure is measured by the fraction of endpoints running unpatched Chrome. Chrome auto-updates within 24-72 hours for consumer installs; enterprise deployments with managed rollout policies may lag 1-4 weeks.
Disclosure & Reporter	Disclosed 2026-06-04 via Chrome stable channel update. Reporter name not publicly disclosed (standard for Chrome VRP reports during restricted disclosure window). No specific bug bounty amount attributed to this CVE in SecurityWeek's coverage of Chrome 149.

Sources.

05 · The Call

Final Verdict

↓ DOWNGRADED to HIGH (6.8/10)

Why this verdict

Two-bug chain prerequisite: This is not a standalone RCE. The attacker must first compromise the renderer via a *separate* high-severity vulnerability before CVE-2026-11113 becomes reachable. CVSS encodes this as PR:N/AC:L, which is factually wrong — the real attack complexity is high. This alone justifies a 2+ point reduction from 9.6.
Chromium's own team rates it Medium (S2): The people who wrote the code, reviewed the bug report, and triaged it against their own severity guidelines — which rate reliable sandbox escapes at High — chose Medium. This signals constrained exploitability: unreliable corruption, hardware-specific triggers, or limited attacker control. When the vendor downgrades their own bug below their own framework's default, defenders should listen.
No weaponization evidence: Zero public PoCs, zero KEV listing, zero in-the-wild exploitation, EPSS at the 18th percentile. Nearly four months post-disclosure with no observed activity. Sophisticated actors capable of chaining renderer RCE + sandbox escape typically target zero-days, not patched bugs with limited reliability.
Chrome auto-update collapses the exposure window: Consumer Chrome installs patch within 24-72 hours. Enterprise managed deployments with GoogleUpdate or MDM policies typically roll out within 1-4 weeks. By the time an attacker could weaponize this chain, the vast majority of the fleet is already patched.
Role multiplier: Chrome is a *client-side endpoint application*, not a canonically high-value-role component (not a hypervisor, IdP, domain controller, PAM system, backup infrastructure, or network edge appliance). The blast radius of a successful exploit is host-level: the attacker compromises one user's workstation at user-level privileges. While that workstation *could* belong to an admin (making it a pivot point), this is true of any endpoint application and does not elevate the blast radius to domain/fleet/supply-chain scale. Chrome's ubiquity means many hosts are theoretically in scope, but the two-bug chain and auto-update severely limit practical reachability. No floor constraint applies.

Why not higher?

A CRITICAL rating would require either standalone remote code execution without prerequisites, active in-the-wild exploitation, or a blast radius that reaches domain/fleet/supply-chain scale. CVE-2026-11113 has none of these. It requires chaining with a separate renderer RCE that is itself a high-value exploit, and even then the sandbox escape is described as 'potential' rather than reliable. Chromium's own team — the best judges of their own attack surface — rated it below their own High threshold.

Why not lower?

Despite the steep prerequisites, sandbox escapes in browser GPU processes remain a high-value capability. ANGLE handles GPU IPC for every WebGL-enabled page and runs with elevated privileges relative to the renderer. The bug affects all desktop platforms and all Chromium-based browsers. If a capable adversary chains this with a working renderer RCE, the result is full host compromise — a meaningful outcome even at user-level privileges. Dropping to MEDIUM would understate the impact for the subset of enterprises with slow Chrome update cycles or high-value users (executives, admins, developers) whose workstations are attractive targets.

06 · Verification

Crowdsourced verification payload.

Run this script on each target endpoint (Linux or macOS) as any user. It checks the installed Chrome/Chromium version against the patched version 149.0.7827.53. Example: chmod +x check_cve_2026_11113.sh && ./check_cve_2026_11113.sh. No elevated privileges required. For Windows, use the PowerShell alternative below or query the registry key HKLM\SOFTWARE\Google\Chrome\BLBeacon\version.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash
# check_cve_2026_11113.sh — Detect CVE-2026-11113 (ANGLE sandbox escape)
# Target: Linux / macOS endpoints with Chrome or Chromium installed
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

PATCHED_VERSION="149.0.7827.53"

# Locate Chrome binary
CHROME_BIN=""
for candidate in google-chrome google-chrome-stable chromium-browser chromium \
    "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"; do
    if command -v "$candidate" &>/dev/null || [ -x "$candidate" ]; then
        CHROME_BIN="$candidate"
        break
    fi
done

if [ -z "$CHROME_BIN" ]; then
    echo "UNKNOWN — Chrome/Chromium not found on this host."
    exit 2
fi

# Extract version
INSTALLED_VERSION=$("$CHROME_BIN" --version 2>/dev/null | grep -oE '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+' | head -1)

if [ -z "$INSTALLED_VERSION" ]; then
    echo "UNKNOWN — Could not determine Chrome version."
    exit 2
fi

echo "Installed Chrome version: $INSTALLED_VERSION"
echo "Patched version:          $PATCHED_VERSION"

# Compare versions using sort -V
LOWER=$(printf '%s\n%s' "$INSTALLED_VERSION" "$PATCHED_VERSION" | sort -V | head -1)

if [ "$INSTALLED_VERSION" = "$PATCHED_VERSION" ] || [ "$LOWER" = "$PATCHED_VERSION" ]; then
    echo "PATCHED — Chrome $INSTALLED_VERSION >= $PATCHED_VERSION. CVE-2026-11113 is fixed."
    exit 0
else
    echo "VULNERABLE — Chrome $INSTALLED_VERSION < $PATCHED_VERSION. CVE-2026-11113 is exploitable."
    exit 1
fi