← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-11119 · CWE-20 · Disclosed 2026-06-04

Inappropriate implementation in GPU in Google Chrome on Android prior to 149

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

This is a hole in the inner fence, not the front gate

CVE-2026-11119 is a GPU-side Chrome-on-Android bug that can help an attacker escape the renderer sandbox, but only after they already have code execution or equivalent control inside the renderer. The CVE record says Chrome on Android versions before 149.0.7827.53 are affected; Google’s Android stable release carrying the fix shipped as 149.0.7827.59, and Google states Android contains the same security fixes as the corresponding desktop release.

The 9.6 vendor/NVD-style CVSS label overstates operational urgency for enterprise patching. In the real world this is a *chain completion* bug, not an initial-access bug: it requires user interaction, a crafted page, and most importantly a separate renderer compromise first; Google’s own Chromium release notes classify it as Medium, which better matches defender reality.

"Serious only as the second half of a browser exploit chain, not as a stand-alone fire drill"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Get the victim into attacker-controlled web content

The attacker needs the Android user to load a crafted page, typically via phishing, malvertising, or a compromised site. By itself this does nothing special; it only puts the victim in position for a browser exploit chain.
Conditions required:
  • Victim uses Chrome on Android
  • Victim visits attacker-controlled or attacker-influenced HTML content
  • Chrome version is unpatched
Where this breaks in practice:
  • Requires user interaction
  • Safe browsing, URL filtering, and user behavior reduce click-through
  • Not reachable as a blind network service
Detection/coverage: Web proxies, DNS filters, mobile threat defense, and Safe Browsing may catch delivery, but vuln scanners generally cannot prove exploitability from the network.
STEP 02

Land a separate renderer compromise

The decisive prerequisite is a different bug or exploit primitive that compromises the Chrome renderer process first. Public reporting for this CVE explicitly says the attacker must have already compromised the renderer process, which makes CVE-2026-11119 a second-stage exploit component rather than a self-starting bug.
Conditions required:
  • A separate renderer RCE/memory-corruption bug or equivalent exploit primitive
  • Successful execution inside the renderer sandbox
Where this breaks in practice:
  • This CVE is not enough on its own
  • Chaining costs real exploit development effort
  • No public PoC or turnkey exploit chain was found
Detection/coverage: Version scanners will miss the chain requirement. Detection depends on exploit telemetry, crash analytics, browser hardening signals, and threat intel rather than simple CVE matching.
STEP 03

Use the GPU bug to cross the sandbox boundary

Once the attacker has renderer foothold, the crafted page can exercise the vulnerable GPU path to attempt a sandbox escape. That turns a renderer-only compromise into broader browser-process access, which is exactly why this class matters even when it is not a front-door bug.
Conditions required:
  • Renderer already compromised
  • GPU code path reachable from malicious content
  • Target remains on a vulnerable Chrome build
Where this breaks in practice:
  • Exploit reliability is usually lower for chained sandbox escapes
  • Platform and device variance on Android can hurt portability
  • Bug details are still restricted in Chromium issue tracking
Detection/coverage: Exploit prevention on Android is uneven across fleets. MDM can verify version; it cannot verify whether a sandbox-escape attempt succeeded.
STEP 04

Expand impact beyond renderer isolation

Successful exploitation potentially breaks renderer isolation and gives the attacker execution outside the renderer sandbox. That can expose browser data and enable follow-on local privilege escalation attempts, but this CVE alone does not equal full device compromise.
Conditions required:
  • Successful sandbox escape
  • Useful post-escape objectives on the handset
Where this breaks in practice:
  • Further privilege escalation is not guaranteed
  • Impact is bounded to Android Chrome users rather than servers or broad internet services
  • Enterprise Android fleets are often smaller than desktop browser populations
Detection/coverage: Post-exploit evidence may show up in crash reports, EDR/Mobile Threat Defense telemetry, or anomalous browser process behavior, but external attack-surface scanners provide little value here.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence of active exploitation found, and not KEV-listed as of 2026-06-06.
Proof-of-concept availabilityNo public PoC or GitHub exploit chain surfaced in searches. Chromium issue 501461853 exists, but bug details remain restricted.
EPSS0.00047 (~0.047%) from the user intel, which is very low empirical near-term exploit likelihood.
KEV statusAbsent from CISA KEV; no KEV date applies.
Vendor vs realityUser-supplied vendor/NVD-style severity is CRITICAL 9.6, but Chrome release notes label CVE-2026-11119 as Medium.
CVSS interpretationCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H scores like a remote browser chain, but it does not encode the explicit renderer-compromise prerequisite well enough for patch prioritization.
Affected versionsCVE record says Chrome on Android prior to 149.0.7827.53.
Fixed versionGoogle shipped Chrome 149.0.7827.59 for Android and states it carries the same security fixes as the corresponding desktop release.
Exposure and scanning realityThis is a client-side mobile browser issue, not an internet-facing server. Shodan/Censys/FOFA-style exposure counts are therefore not meaningful; inventory must come from MDM, Play, EMM, or adb-style host checks.
Disclosure and reportingPublicly disclosed 2026-06-04; Chrome release notes say it was reported by Google on 2026-04-10.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (5.8/10)

The single biggest downgrade factor is the already-compromised renderer requirement. That makes this a post-exploitation chain component with a sharply smaller reachable population than a true unauthenticated remote browser bug, despite the scary theoretical impact if chained successfully.

HIGH The renderer-compromise prerequisite materially lowers real-world severity
MEDIUM No current public exploitation or PoC evidence

Why this verdict

  • Post-compromise prerequisite: start from vendor 9.6, then subtract hard because the attacker must first compromise the renderer process; this is not a one-bug drive-by.
  • Android-only population: the affected surface is limited to Chrome on Android, not your desktop fleet and not any server-side estate, which narrows blast radius for most enterprises.
  • Low threat signal: no KEV, no public exploitation evidence found, and EPSS 0.00047 argue against emergency treatment.

Why not higher?

If this were a stand-alone renderer RCE or an actively exploited sandbox escape, it would move up fast. But the need for a separate renderer bug first is compounding friction that collapses the exposed population from 'anyone browsing' to 'victims already hit by another exploit stage.'

Why not lower?

Sandbox escapes are not harmless cleanup bugs; they are exactly what attackers need to turn renderer compromise into something more valuable. Chrome is also widely deployed and often preinstalled on Android, so if you do run a managed Android fleet, the issue is real enough to patch in routine cadence rather than ignore.

05 · Compensating Control

What to do — in priority order.

  1. Enforce Chrome auto-update on managed Android — Use Play/EMM policy so com.android.chrome updates automatically and reaches a fixed build during your normal mobile maintenance cycle; for a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but do not let unmanaged Play settings decide your compliance.
  2. Measure version compliance from MDM or device shell — Create a compliance rule for Chrome Android versions and flag anything below the fixed Android build. This is the only scalable way to know whether the fleet actually moved, and for a MEDIUM verdict it should be completed inside the <=365 day remediation window, ideally in the next routine reporting cycle.
  3. Reduce hostile-content exposure on mobile — Keep Safe Browsing, DNS filtering, secure web gateways, and mobile threat defense enabled because step 1 of the chain still needs the victim to reach malicious content. That does not replace patching, but it meaningfully cuts exploit delivery while you work through the normal remediation window.
  4. Block sideloading and non-managed browsers where possible — Attackers benefit from version drift and alternate APK delivery. Enforce managed app sources and browser standards so fixed Chrome reaches devices predictably within the same <=365 day remediation window.
What doesn't work
  • A WAF or perimeter IPS does not meaningfully help here because this is a client-side browser issue, not a server-side HTTP service.
  • Desktop Chrome patching only misses the actual affected population; this CVE is specific to Chrome on Android.
  • Network vulnerability scanning will not prove exploitability or even identify most affected devices; you need device/app inventory, not port scans.
06 · Verification

Crowdsourced verification payload.

Run this from an auditor workstation that has adb installed and can talk to managed Android devices over USB or your remote device shell workflow. Invoke it as python3 chrome_android_cve_check.py --all or python3 chrome_android_cve_check.py --device SERIAL; it needs no root, but it does need access to adb shell dumpsys package com.android.chrome.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# chrome_android_cve_check.py
# Check Android Chrome version for CVE-2026-11119 exposure.
# Exit codes:
#   0 = all checked targets PATCHED
#   1 = at least one checked target VULNERABLE
#   2 = UNKNOWN / operational error / no targets

import argparse
import re
import shutil
import subprocess
import sys

FIXED_VERSION = "149.0.7827.59"  # Android stable release carrying the fix
PACKAGE = "com.android.chrome"


def parse_version(text):
    m = re.search(r"(\d+)\.(\d+)\.(\d+)\.(\d+)", text)
    if not m:
        return None
    return tuple(int(x) for x in m.groups())


def compare_versions(a, b):
    return (a > b) - (a < b)


def run(cmd):
    return subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True)


def adb_base(serial=None):
    base = ["adb"]
    if serial:
        base += ["-s", serial]
    return base


def get_devices():
    p = run(["adb", "devices"])
    if p.returncode != 0:
        return None, p.stderr.strip() or p.stdout.strip()
    devices = []
    for line in p.stdout.splitlines()[1:]:
        line = line.strip()
        if not line:
            continue
        parts = line.split()
        if len(parts) >= 2 and parts[1] == "device":
            devices.append(parts[0])
    return devices, ""


def get_chrome_version(serial):
    cmd = adb_base(serial) + ["shell", "dumpsys", "package", PACKAGE]
    p = run(cmd)
    if p.returncode != 0:
        return None, f"adb command failed: {p.stderr.strip() or p.stdout.strip()}"

    # Look for versionName in dumpsys output
    m = re.search(r"versionName=([^\s]+)", p.stdout)
    if m:
        return m.group(1).strip(), ""

    # Fallback: package may be missing or output restricted
    if "Unable to find package" in p.stdout or "Unable to find package" in p.stderr:
        return None, f"package {PACKAGE} not installed"

    return None, "could not determine versionName"


def check_device(serial):
    version_str, err = get_chrome_version(serial)
    if version_str is None:
        return {"serial": serial, "status": "UNKNOWN", "detail": err}

    current = parse_version(version_str)
    fixed = parse_version(FIXED_VERSION)
    if current is None or fixed is None:
        return {"serial": serial, "status": "UNKNOWN", "detail": f"unparseable version: {version_str}"}

    if compare_versions(current, fixed) >= 0:
        return {"serial": serial, "status": "PATCHED", "detail": version_str}
    return {"serial": serial, "status": "VULNERABLE", "detail": version_str}


def main():
    parser = argparse.ArgumentParser(description="Check Android Chrome for CVE-2026-11119")
    group = parser.add_mutually_exclusive_group(required=True)
    group.add_argument("--device", help="single adb device serial")
    group.add_argument("--all", action="store_true", help="check all connected adb devices")
    args = parser.parse_args()

    if shutil.which("adb") is None:
        print("UNKNOWN - adb not found in PATH")
        sys.exit(2)

    if args.device:
        targets = [args.device]
    else:
        targets, err = get_devices()
        if targets is None:
            print(f"UNKNOWN - failed to enumerate devices: {err}")
            sys.exit(2)
        if not targets:
            print("UNKNOWN - no adb devices connected")
            sys.exit(2)

    results = [check_device(t) for t in targets]

    any_vuln = False
    any_unknown = False
    for r in results:
        print(f"{r['serial']}: {r['status']} - {r['detail']}")
        if r["status"] == "VULNERABLE":
            any_vuln = True
        elif r["status"] == "UNKNOWN":
            any_unknown = True

    if any_vuln:
        sys.exit(1)
    if any_unknown:
        sys.exit(2)
    sys.exit(0)


if __name__ == "__main__":
    main()
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, do not treat this like an enterprise-wide Chrome zero-day fire drill. Triage your managed Android Chrome population, verify which devices are below the fixed build, keep normal mobile web protections on, and use your next routine mobile-app push to move them; for a MEDIUM verdict there is noisgate mitigation SLA for temporary controls — no mitigation SLA — go straight to the 365-day remediation window — and the noisgate remediation SLA is <=365 days to get the actual Chrome update deployed across the fleet.

Sources

  1. Google Chrome Releases - Stable Channel Update for Desktop
  2. Google Chrome Releases - Chrome for Android Update
  3. Chromium issue 501461853
  4. Tenable CVE entry for CVE-2026-11119
  5. CIRCL Vulnerability-Lookup entry stream
  6. CISA Known Exploited Vulnerabilities Catalog
  7. FIRST EPSS data and statistics
  8. Google Chrome Help - Update Google Chrome on Android
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.