Heap buffer overflow in ANGLE in Google Chrome on Android prior to 149

CVE-2026-10929 is a heap buffer overflow in ANGLE, Chrome's graphics translation layer used to service WebGL/OpenGL ES work. In practice, this sits on the path between a compromised renderer and the less-restricted GPU/browser side of Chrome on Android. The user-supplied intel says affected versions are Google Chrome on Android prior to 149.0.7827.53; Google's June 2, 2026 Android stable release was 149.0.7827.59, and Google states Android carries the same security fixes as the corresponding desktop 149.0.7827.53/54 release unless otherwise noted.

Google's HIGH 8.3 label is technically fair in isolation because memory corruption in a graphics boundary is exactly the kind of bug that can become sandbox escape material. But for enterprise patch prioritization, the real-world story is narrower: this bug does not give an unauthenticated remote attacker code execution by itself; it assumes the attacker has already compromised the renderer. That turns this from front-door browser RCE into a post-compromise chain component, which is why the vendor score overstates the immediate fleet-wide urgency.

Why this verdict

• Renderer compromise prerequisite cuts the score down hard: this is not internet-to-RCE by itself; it is a post-renderer-compromise sandbox-boundary bug, so I discount the vendor's 8.3 baseline substantially.
• Android client-side population is real but not perimeter-exposed: you cannot mass-scan for this like VPNs, firewalls, or edge appliances; reachability depends on user browsing plus a separate first-stage exploit.
• No active exploitation pressure: no KEV listing, no public PoC found in the consulted sources, and the supplied EPSS 0.00062 is about as non-urgent as browser memory corruption gets.
• Impact is still meaningful once hit: Chromium documents that Android renderers run in isolated_app, while unsandboxed GPU/browser-side components run with the browser app's UID, so a successful exploit can materially expand attacker rights inside Chrome.

Why not higher?

If this were a one-click remote code execution bug or there were credible evidence of active exploitation, it would move up fast. But the prerequisite chain is too restrictive: user interaction, high complexity, mobile-browser targeting, and an explicit need for prior renderer compromise all compound downward pressure.

Why not lower?

I am not calling this LOW because browser sandbox escapes still matter to real attackers, especially on widely deployed software like Chrome. Once an attacker has renderer execution, a working ANGLE overflow can widen access beyond the isolated renderer and become a valuable second-stage primitive in a full exploit chain.

1. Enforce Chrome auto-update via MDM — Make Google Chrome for Android update compliance a managed-device policy and flag any device below 149.0.7827.59. Because this is a MEDIUM verdict, there is no mitigation SLA — go straight to the 365-day remediation window, but in practice mobile app updates should be cleaned up much sooner through normal compliance drift handling.
2. Inventory version drift now — Pull an app-version report for com.android.chrome from your EMM/MDM and identify devices pinned behind Play updates, kiosk modes, or user-disabled updates. For this verdict there is no mitigation SLA, so the operational job is accurate scoping and patch completion within the remediation window.
3. Prioritize high-risk Android cohorts — Move executives, admins, developers, and mobile users with broad web exposure to the front of the update queue because exploit chains usually target the people who browse risky content and hold useful tokens. Again, no mitigation SLA applies for MEDIUM; the goal is to compress patching through normal endpoint hygiene before the 365-day remediation ceiling.
4. Keep Safe Browsing and Play Protect enabled — These will not fix the vulnerability, but they can reduce first-stage delivery opportunities by filtering known malicious pages and risky app behavior. Use them as exposure reducers while you complete version remediation within the MEDIUM-severity patch window.

Run this on an auditor workstation with adb installed and an authorized Android device connected over USB or TCP/IP debugging. Invoke it as ./check_chrome_android.sh SERIAL_OR_TRANSPORT_ID or set ADB_SERIAL; no root is required on the device, but USB debugging authorization is required.

#!/usr/bin/env bash
# check_chrome_android.sh
# Determine whether Google Chrome on Android is patched for CVE-2026-10929.
# Practical fixed baseline: 149.0.7827.59 or later.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=usage/environment error

set -u

PKG="com.android.chrome"
FIXED="149.0.7827.59"
SERIAL="${1:-${ADB_SERIAL:-}}"

fail() {
  echo "UNKNOWN: $1"
  exit 2
}

if ! command -v adb >/dev/null 2>&1; then
  echo "UNKNOWN: adb not found in PATH"
  exit 3
fi

ADB=(adb)
if [ -n "$SERIAL" ]; then
  ADB+=( -s "$SERIAL" )
fi

if ! "${ADB[@]}" get-state >/dev/null 2>&1; then
  echo "UNKNOWN: adb device not available or not authorized"
  exit 2
fi

version="$(("${ADB[@]}" shell dumpsys package "$PKG" 2>/dev/null || true) | tr -d '\r' | sed -n 's/.*versionName=//p' | head -n 1)"

if [ -z "$version" ]; then
  version="$(("${ADB[@]}" shell cmd package resolve-activity --brief "$PKG" 2>/dev/null || true) | tr -d '\r' >/dev/null; ("${ADB[@]}" shell pm dump "$PKG" 2>/dev/null || true) | tr -d '\r' | sed -n 's/.*versionName=//p' | head -n 1)"
fi

if [ -z "$version" ]; then
  echo "UNKNOWN: package $PKG not found or version could not be read"
  exit 2
fi

normalize() {
  local IFS=.
  local parts=($1)
  printf "%d.%d.%d.%d\n" \
    "${parts[0]:-0}" "${parts[1]:-0}" "${parts[2]:-0}" "${parts[3]:-0}"
}

ver_lt() {
  local a b IFS=.
  read -r -a a <<<"$(normalize "$1")"
  read -r -a b <<<"$(normalize "$2")"
  for i in 0 1 2 3; do
    if [ "${a[$i]}" -lt "${b[$i]}" ]; then
      return 0
    elif [ "${a[$i]}" -gt "${b[$i]}" ]; then
      return 1
    fi
  done
  return 1
}

if ver_lt "$version" "$FIXED"; then
  echo "VULNERABLE: $PKG version $version is older than fixed baseline $FIXED"
  exit 1
else
  echo "PATCHED: $PKG version $version is at or above fixed baseline $FIXED"
  exit 0
fi

Sources

1. Chrome Releases 2026 index (includes CVE-2026-10929 listing and Chrome 149 stable notes)
2. Early Stable Update for Desktop 149.0.7827.53/.54
3. Chrome Android sandbox design
4. Chromium GPU process / command buffer architecture
5. ANGLE project README
6. CISA Known Exploited Vulnerabilities Catalog
7. FIRST EPSS overview
8. Canadian Centre for Cyber Security Chrome advisory for 149.0.7827.53/54 train