CVE-2026-11119 · Chrome Android GPU Inappropriate Implementation Sandbox Escape

01 · The Real Story

This is a locked second door inside a building the attacker hasn't broken into yet

CVE-2026-11119 is an inappropriate implementation in the GPU process of Google Chrome on Android only, affecting all versions prior to 149.0.7827.53. The flaw allows an attacker who has already compromised the renderer process (via a separate, unrelated vulnerability) to craft malicious GPU command sequences that corrupt memory structures in the higher-privileged GPU process, achieving a sandbox escape. The affected component is Chrome's GPU IPC layer on Android, which validates commands coming from the sandboxed renderer; the validation logic can be bypassed to trigger an out-of-bounds write. Successful exploitation gives the attacker code execution at the privilege level of the Chrome application on the Android device — but still within Android's per-app sandbox.

The NVD assigned a 9.6 CRITICAL score using the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H, which treats this as a near-trivial remote exploit requiring only that a user visit a page. This is a gross misrepresentation of the actual attack requirements. The description literally says 'a remote attacker who had compromised the renderer process' — meaning a separate, independently valuable RCE vulnerability must fire first. Google's own Chromium security team, who built the sandbox architecture, rated this Medium. That is far more honest. A Medium-severity chain link that requires a High/Critical prerequisite exploit, has no public PoC, no in-the-wild exploitation, an EPSS of 0.23%, and only targets Android — is not a CRITICAL vulnerability by any reasonable operational standard.

"Sandbox escape in Chrome Android GPU, but needs a separate renderer exploit first — chain link, not a chain starter."

02 · The Attack Path

4 steps from start to impact.

STEP 01

Obtain a Chrome renderer exploit

The attacker needs a separate vulnerability — typically a V8 JIT bug, Blink use-after-free, or WebAssembly type confusion — to achieve code execution inside Chrome's renderer (site) process. These are high-value primitives; public renderer 0-days for Chrome are rare and typically worth $200K+ on the exploit market. Without this prerequisite, CVE-2026-11119 is entirely unreachable.

Conditions required:

A separate, unpatched Chrome renderer RCE vulnerability
Target running Chrome for Android < 149.0.7827.53

Where this breaks in practice:

Chrome renderer exploits are scarce and expensive
Chrome's V8 sandbox and MiraclePtr mitigations make renderer exploitation increasingly difficult in 2026
Auto-update on Android closes the window rapidly

STEP 02

Lure victim to attacker-controlled page

The attacker must get the target to navigate to a page hosting the exploit chain on Chrome for Android. This requires social engineering (phishing link, watering hole, malvertising) and the user must be on an Android device specifically — iOS, desktop Windows, macOS, Linux, and ChromeOS are not affected.

Conditions required:

User interaction: victim must click a link or navigate to attacker page
Victim must be using Chrome on Android, not any other platform

Where this breaks in practice:

Enterprise mobile devices often route through secure web gateways or have URL filtering
Android-only narrows the target population vs. all Chrome users
Google Safe Browsing may flag known exploit domains

Detection/coverage: Google Safe Browsing, enterprise SWG/proxy URL filtering, MDM-managed Chrome policies

STEP 03

Trigger GPU process memory corruption

From the compromised renderer, the attacker sends crafted GPU IPC messages that exploit the inappropriate implementation in the GPU command validation logic. This triggers an out-of-bounds write in the GPU process's memory space, allowing the attacker to overwrite critical data structures or redirect execution flow.

Conditions required:

Renderer process already compromised (Step 1 succeeded)
Specific GPU driver and hardware combination on victim's Android device

Where this breaks in practice:

GPU process memory layout varies across Android OEMs, SoCs (Qualcomm Adreno, ARM Mali, PowerVR), and driver versions
Exploit reliability is hardware-dependent; a single PoC won't work universally across the Android device ecosystem
No public PoC exists

STEP 04

Escape to GPU process privilege level

Successful memory corruption gives the attacker code execution in the GPU process, which runs at a higher privilege level than the renderer and has direct access to graphics hardware. However, on Android, this is still within Chrome's application sandbox — the attacker has escaped the renderer sandbox but not the Android OS-level app sandbox. Further exploitation would require an Android kernel or system service vulnerability to achieve true device compromise.

Conditions required:

Step 3 must succeed on the specific device hardware
GPU process must not have been further hardened by the OEM

Where this breaks in practice:

Android's per-app SELinux policies and seccomp filters still constrain the GPU process
Full device compromise requires ANOTHER exploit (Android kernel/system service)
Most enterprise-relevant data (corporate email, MDM payloads) lives in separate managed profiles with additional isolation

Detection/coverage: Android system integrity checks, Play Protect, MDM compliance reporting

03 · Compensating Control

MEDIUM 5.0→LOW 2.5

SEVERITY REDUCED

Verify Chrome auto-update is not blocked on managed Android devices — Chrome on Android updates automatically via the Play Store. However, MDM policies or enterprise configurations can delay or block updates. Confirm via your MDM console (Intune, Workspace ONE, SOTI) that Chrome updates are not deferred and that managed devices are running 149.0.7827.53 or later. No mitigation SLA applies for MEDIUM — go straight to the 365-day remediation window, but since the patch has been available for ~4 months, most devices should already be current.

MEDIUM 5.0→LOW 3.0

SEVERITY REDUCED

Enforce Chrome browser-level policies via Chrome Enterprise Core — Push managed Chrome policies to Android devices that restrict navigation to untrusted sites. Enable SafeBrowsingProtectionLevel at Enhanced Protection, block known exploit-serving domains via URLBlocklist, and enable SitePerProcess (site isolation). These controls blunt the social engineering step required to deliver the initial renderer exploit. Deploy within the 365-day remediation window.

MEDIUM 5.0→LOW 2.0

SEVERITY REDUCED

Deploy a mobile threat defense (MTD) agent on managed Android devices — MTD solutions (Lookout, Zimperium, CrowdStrike Falcon for Mobile) can detect renderer exploitation attempts, suspicious GPU process behavior, and sandbox escape indicators on Android. If not already deployed, this is a long-term security investment rather than a CVE-specific response. Treat as backlog hygiene aligned with the 365-day MEDIUM remediation window.

MEDIUM 5.0→IGNORE 1.5

SEVERITY REDUCED

Restrict corporate data to Android work profiles with managed app configurations — Ensure corporate email, SSO tokens, and sensitive apps are deployed exclusively in the Android work profile (managed by Android Enterprise). Even if Chrome in the personal profile is compromised, work profile data remains isolated by Android's kernel-level container separation. This limits blast radius to personal browsing data.

What doesn't work

Network-level WAF or IPS — This is a client-side browser vulnerability exploited via page content rendered locally. Network inspection cannot see or block the GPU IPC manipulation happening inside the browser process on the device.
VPN or ZTNA — Routing traffic through a VPN does not prevent the user from visiting an attacker-controlled page, and the exploit fires inside the browser process regardless of network path.
Revoking Chrome permissions on Android — Chrome requires GPU access to function; you cannot disable GPU usage without effectively disabling the browser.

04 · Intelligence Metadata

The supporting signals.

In-the-wild exploitation	None reported. Not listed in CISA KEV. No campaigns or threat actor usage documented. No GreyNoise or Shadowserver observations (client-side browser vuln, not scannable).
Proof-of-concept	No public PoC found. Checked pocindex.io, GitHub (no repos named CVE-2026-11119), ExploitDB, and nuclei templates. The Chromium bug (Issue #501461853) is likely still access-restricted.
EPSS	0.00234 (0.23%), 14th percentile. Extremely low exploitation probability, consistent with a chained prerequisite vulnerability on a mobile-only platform.
KEV status	Not listed. No CISA KEV entry as of 2026-09-30.
CVSS vector	`CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H` — misleading. The vector encodes AV:N/AC:L/PR:N as if the bug itself is network-reachable with low complexity and no privileges. In reality, exploitation requires a prior renderer compromise (PR should be High, AC should be High). Scope:Changed is accurate (renderer→GPU process boundary). NVD score 9.6; Chromium's own rating: Medium.
Chromium severity	Medium per Google's Chromium Security Severity Guidelines. Google rates sandbox escapes from a compromised renderer as Medium when the implementation flaw is in a non-default or constrained code path. This is the authoritative rating from the vendor who designed the sandbox.
Affected versions	Google Chrome for Android only, all versions prior to `149.0.7827.53`. Desktop Chrome (Windows, macOS, Linux) and ChromeOS are not affected.
Fixed version	`149.0.7827.53` (Android). Released 2026-06-02 via Play Store. Ubuntu marks chromium-browser as 'Not affected' across all releases (Snap delivery). Debian tracks under DEBIAN-CVE-2026-11119.
Disclosure date	2026-06-04 (NVD published). Last modified 2026-07-23.
Reporter	Not publicly attributed. Chromium bug #501461853 is access-restricted; no researcher name or bug bounty amount disclosed in release notes.

Sources.

05 · The Call

Final Verdict

↓ DOWNGRADED to MEDIUM (5.0/10)

Why this verdict

Chained prerequisite is the dealbreaker. The vulnerability explicitly requires a *prior compromise of the renderer process* via a separate, unrelated RCE bug. This makes CVE-2026-11119 a second-stage chain link, not a standalone exploit. The NVD CVSS vector incorrectly encodes this as PR:N/AC:L, dramatically inflating the score.
Chromium's own team says Medium. Google's security engineers — who built the multi-process sandbox architecture — rated this Medium. They have full context on the exploitability constraints, internal hardening (MiraclePtr, V8 sandbox, PartitionAlloc), and actual attack surface. Their assessment deserves significantly more weight than NVD's mechanical scoring.
Android-only, no PoC, no exploitation. The attack surface is limited to Chrome on Android. There is no public proof-of-concept, no in-the-wild exploitation, no KEV listing, and EPSS is at the 14th percentile (0.23%). The combination of a chained prerequisite on a single mobile platform with zero evidence of weaponization does not justify CRITICAL or HIGH.
Even success doesn't mean full compromise. Escaping the renderer sandbox to the GPU process on Android still leaves the attacker inside Chrome's application sandbox. Android's per-app SELinux policies, seccomp-bpf filters, and managed work profile isolation mean the attacker needs *yet another* exploit (kernel or system service) for meaningful device compromise.
Role multiplier: No high-value infrastructure role. Chrome on Android is a client-side mobile browser. It does not serve as a domain controller, hypervisor, CI/CD runner, PKI component, backup system, network edge appliance, or any other high-value role from the deployment-role catalog. The blast radius of a successful chain is limited to a single user's device sessions and locally cached credentials — there is no fleet-scale, identity-scale, or supply-chain-scale impact. No severity floor applies.
Auto-update narrows the window. Chrome on Android auto-updates via the Play Store. The patch has been available since June 2, 2026 — nearly 4 months. The vast majority of active Chrome Android installations have already updated past 149.0.7827.53, further reducing the exploitable population.

Why not higher?

Promoting this to HIGH would require either evidence of real-world exploitation, a public PoC that lowers the cost of the renderer prerequisite, or a plausible scenario where the blast radius exceeds a single mobile device. None of these conditions exist. The vulnerability is a chain link that cannot fire independently, affects only a mobile browser with no infrastructure role, and even full exploitation still leaves the attacker inside Android's app sandbox. HIGH is not warranted.

Why not lower?

Dropping to LOW or IGNORE would dismiss a real sandbox escape primitive too aggressively. If an attacker *does* possess a renderer exploit, this CVE provides a clean privilege escalation step in the chain. The GPU process has meaningful additional capabilities (graphics hardware access, higher privilege level) compared to the renderer. The bug class (sandbox escape) is inherently significant, even when the prerequisites are steep. MEDIUM correctly reflects a real but heavily gated threat.

06 · Verification

Crowdsourced verification payload.

Run this on a managed Android device via adb shell from a connected workstation, or push it via your MDM's script execution capability. Requires adb access or MDM remote shell. Example: adb shell sh /data/local/tmp/check_cve_2026_11119.sh

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/bin/sh
# CVE-2026-11119 Check — Chrome Android GPU Sandbox Escape
# Run via: adb shell sh /path/to/this_script.sh
# Requires: adb shell access to the Android device
# Output: VULNERABLE / PATCHED / UNKNOWN

PATCHED_VERSION="149.0.7827.53"

# Get installed Chrome version
CHROME_VERSION=$(dumpsys package com.android.chrome 2>/dev/null | grep versionName | head -1 | sed 's/.*versionName=//' | tr -d '[:space:]')

if [ -z "$CHROME_VERSION" ]; then
  # Try Chrome Beta or Dev
  CHROME_VERSION=$(dumpsys package com.chrome.beta 2>/dev/null | grep versionName | head -1 | sed 's/.*versionName=//' | tr -d '[:space:]')
fi

if [ -z "$CHROME_VERSION" ]; then
  echo "UNKNOWN — Chrome not found on this device"
  exit 2
fi

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

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

if [ "$MIN_VERSION" = "$PATCHED_VERSION" ] || [ "$CHROME_VERSION" = "$PATCHED_VERSION" ]; then
  echo "PATCHED — Chrome $CHROME_VERSION >= $PATCHED_VERSION"
  exit 0
else
  echo "VULNERABLE — Chrome $CHROME_VERSION < $PATCHED_VERSION (CVE-2026-11119)"
  exit 1
fi