Integer overflow in GPU in Google Chrome on Android prior to 149

The authoritative record matching your description appears to be CVE-2026-11256, not CVE-2026-11085. It is an integer overflow in the GPU component of Google Chrome on Android affecting versions before 149.0.7827.53. The key detail is the one that changes everything operationally: the attacker must have already compromised the renderer process and then use a crafted HTML page to try to turn that foothold into a sandbox escape.

Your supplied HIGH 8.8 framing overstates the real enterprise urgency. The vendor language says Chromium security severity: Low, and while CISA-ADP later attached a high CVSS-style score, that numeric model still treats the bug too much like a first-hop remote compromise. In the real world this is a post-renderer-compromise chain element on Android only, with no KEV listing, no public exploitation evidence, and extremely low EPSS, so the right move is to downgrade it to a routine browser-update priority rather than a fleet-wide fire drill.

Why this verdict

• Requires prior compromise: an attacker must already control or materially compromise the renderer process before this CVE does anything useful.
• Android-only population: this is not your Windows/Mac/Linux browser fleet; it is a narrower mobile subset with smaller enterprise blast radius.
• No live-fire intel: no KEV listing, no public exploitation evidence, and a near-floor EPSS score argue against emergency treatment.
• Version exposure is common, exploitability is not: lots of devices may be behind on Chrome, but very few real attackers can chain a renderer bug plus a reliable Android GPU sandbox escape.

Why not higher?

This is not a stand-alone drive-by RCE from the open internet. The attack path assumes a prior renderer break, plus reliable exploitation of a GPU memory bug on Android, plus successful sandbox escape. Each prerequisite sharply narrows the number of attackers and targets that can operationalize it.

Why not lower?

It is still a memory-corruption bug in a massively deployed browser component, and its intended end state is a sandbox escape. If you operate a large managed Android fleet, especially with sensitive browser-based workflows, this is worth fixing through normal browser-update discipline rather than treating it as pure backlog trivia.

1. Enforce Chrome auto-update through EMM/Managed Google Play — Make the managed Play policy for com.android.chrome mandatory and verify update deferrals are not pinning devices below 149.0.7827.53. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but this control is low-cost and should be implemented during the next routine mobile policy review.
2. Inventory Android Chrome versions daily — Treat this as an asset-version hygiene problem, not a perimeter exposure problem. Pull app version telemetry from your MDM/UEM and alert on devices below 149.0.7827.53; for MEDIUM, there is no mitigation SLA, so use this to drive orderly remediation inside the 365-day window.
3. Reduce unmanaged browsing paths — Where possible, require corporate browsing through managed Chrome and block alternate unmanaged browsers for sensitive workflows. That does not remove the bug, but it shrinks the population you must trust and gives you version visibility; again, no mitigation SLA applies here, so fold it into normal mobile hardening work.
4. Monitor crash and exploit telemetry on mobile — Watch for clusters of Chrome crashes, browser instability, or vendor/mobile threat-defense alerts that could indicate exploit development against GPU paths. There is no mitigation SLA for this MEDIUM verdict, but telemetry is your early-warning system if the threat picture changes and urgency needs to be re-rated.

Run this on an auditor workstation with Android platform-tools (adb) installed, targeting a managed Android device with USB debugging or enterprise ADB access enabled. Invoke it as ./check_chrome_android.sh <device-serial> for a specific device or ./check_chrome_android.sh when only one device is attached; no root is required on the phone, but you need permission to query package metadata over ADB.

#!/usr/bin/env bash
# check_chrome_android.sh
# Verifies whether Google Chrome on an attached Android device is below 149.0.7827.53.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

FIXED_VERSION="149.0.7827.53"
PACKAGE="com.android.chrome"
SERIAL="${1:-}"

adb_cmd() {
  if [ -n "$SERIAL" ]; then
    adb -s "$SERIAL" "$@"
  else
    adb "$@"
  fi
}

version_lt() {
  # returns 0 if $1 < $2
  local IFS=.
  local i
  local -a a=($1) b=($2)
  local len=${#a[@]}
  if [ ${#b[@]} -gt $len ]; then len=${#b[@]}; fi
  for ((i=0; i<len; i++)); do
    local ai=${a[i]:-0}
    local bi=${b[i]:-0}
    if ((10#$ai < 10#$bi)); then
      return 0
    elif ((10#$ai > 10#$bi)); then
      return 1
    fi
  done
  return 1
}

# Basic device check
if ! adb_cmd get-state >/dev/null 2>&1; then
  echo "UNKNOWN - no accessible Android device via adb"
  exit 2
fi

# Try several methods because OEM builds differ
VERSION="$(adb_cmd shell dumpsys package "$PACKAGE" 2>/dev/null | tr -d '\r' | sed -n 's/.*versionName=//p' | head -n1)"
if [ -z "$VERSION" ]; then
  VERSION="$(adb_cmd shell cmd package list packages -f "$PACKAGE" 2>/dev/null | tr -d '\r' | sed -n 's/.*versionName=//p' | head -n1)"
fi
if [ -z "$VERSION" ]; then
  VERSION="$(adb_cmd shell pm dump "$PACKAGE" 2>/dev/null | tr -d '\r' | sed -n 's/.*versionName=//p' | head -n1)"
fi

if [ -z "$VERSION" ]; then
  # Final fallback: try package manager path presence to distinguish absent vs unreadable
  if adb_cmd shell pm path "$PACKAGE" >/dev/null 2>&1; then
    echo "UNKNOWN - Chrome installed but version could not be read"
  else
    echo "UNKNOWN - Chrome is not installed or package metadata is inaccessible"
  fi
  exit 2
fi

if version_lt "$VERSION" "$FIXED_VERSION"; then
  echo "VULNERABLE - $PACKAGE version $VERSION is below fixed $FIXED_VERSION"
  exit 1
else
  echo "PATCHED - $PACKAGE version $VERSION is at or above fixed $FIXED_VERSION"
  exit 0
fi

Sources

1. NVD detail for the authoritative matching record
2. Chrome Early Stable desktop update 149.0.7827.53/.54
3. Chrome for Android update 149.0.7827.48 rollout
4. Chromium issue tracker reference for this bug
5. CISA Known Exploited Vulnerabilities catalog
6. FIRST EPSS project overview
7. CVE.report aggregation including EPSS snapshot