Use after free in Core in Google Chrome on Android prior to 149

CVE-2026-10953 is a use-after-free in Chrome Core affecting Google Chrome on Android before 149.0.7827.53. In practical terms, the bug matters only after an attacker has already compromised the renderer process, then uses a crafted HTML page to try to break out of Chrome's sandbox. Google’s Android stable rollout on June 2, 2026 shipped Chrome 149.0.7827.59 and explicitly states Android carries the same security fixes as desktop 149.0.7827.53/54.

Google's HIGH 8.3 label is fair in a lab chain, but too hot for enterprise patch triage by itself. The decisive friction is the prerequisite: the attacker must already own the renderer, which makes this a post-initial-execution sandbox escape, not an internet-reachable first-hop compromise; add low EPSS, no KEV entry, no public exploitation evidence, and no public PoC, and this lands lower in a real 10,000-device queue.

Why this verdict

• Renderer compromise required: -1.7 This is not initial access. Requiring a compromised renderer implies the attacker has already landed a separate browser exploit stage, which is compounding friction in real operations.
• Client-side mobile population only: -0.3 The affected population is broad in theory, but only among Android Chrome clients; there is no server-side blast radius and no externally reachable enterprise service to mass-scan or mass-exploit.
• No current exploitation pressure: -0.1 No KEV listing, low EPSS, restricted bug details, and no public PoC reduce immediate weaponization likelihood compared with browser zero-days that are already burning.

Why not higher?

If this were a stand-alone renderer RCE or had confirmed in-the-wild exploitation, it would stay in HIGH without much debate. But a sandbox escape that explicitly requires prior renderer compromise is a chain component, and enterprise prioritization should score chain friction, not just theoretical end-state impact.

Why not lower?

This is still a sandbox escape in Chrome, and that boundary matters. In the hands of a capable actor with a paired renderer bug, the impact can be serious for targeted users, so writing it off as backlog-only hygiene would understate the risk.

1. Force Chrome auto-update on managed Android — Push managed Google Play auto-update enforcement and verify devices move to a fixed Chrome build. For a MEDIUM noisgate verdict there is no mitigation SLA — go straight to the remediation window, so use this as the primary control while ensuring patch completion within 365 days.
2. Prioritize high-risk mobile user groups — Apply accelerated update verification for executives, admins, researchers, and users routinely targeted by web-delivered exploits. There is no mitigation SLA at this severity, but these cohorts deserve earlier internal priority because a sandbox escape is most valuable in targeted chains; still complete broad remediation within 365 days.
3. Keep Safe Browsing and Play Protect enforced — These controls do not fix the bug, but they raise the cost of delivering the first-stage renderer compromise that this CVE depends on. Treat them as hardening rather than mitigation; no mitigation SLA applies, and the real requirement remains patching Chrome within 365 days.
4. Use MDM compliance to quarantine stale Chrome builds — Inventory com.android.chrome versions and flag devices below the fixed threshold for follow-up or conditional access pressure. This is the only scalable way to manage exposure for a client-side mobile browser issue; no mitigation SLA applies, but remediation should still close within 365 days.

Run this on an auditor workstation with adb installed against a connected Android device, or through a remote shell workflow that exposes package metadata. Invoke it as ./check_cve_2026_10953.sh SERIAL or ./check_cve_2026_10953.sh for the only attached device; no root is required, but you do need USB debugging or an enterprise-approved shell channel.

#!/usr/bin/env bash
# check_cve_2026_10953.sh
# Verify whether Google Chrome on Android is below the fix level for CVE-2026-10953.
# Outputs one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

TARGET_SERIAL="${1:-}"
PACKAGE="com.android.chrome"
MIN_SAFE="149.0.7827.53"

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

version_ge() {
  # returns 0 if $1 >= $2
  local IFS=.
  local i
  local -a a=($1) b=($2)
  local len=${#a[@]}
  if (( ${#b[@]} > 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 0
}

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

if ! "${adb_cmd[@]}" get-state >/dev/null 2>&1; then
  echo "UNKNOWN: no reachable Android device/emulator via adb"
  exit 2
fi

pkg_out=$("${adb_cmd[@]}" shell dumpsys package "$PACKAGE" 2>/dev/null)
if [[ -z "$pkg_out" ]]; then
  echo "UNKNOWN: package $PACKAGE not found or dumpsys unavailable"
  exit 2
fi

version=$(printf '%s
' "$pkg_out" | sed -n 's/.*versionName=\([^[:space:]]*\).*/\1/p' | head -n1 | tr -d '\r')
if [[ -z "$version" ]]; then
  version=$("${adb_cmd[@]}" shell cmd package list packages -f "$PACKAGE" 2>/dev/null | tr -d '\r' | sed -n 's/.*versionName=\([^[:space:]]*\).*/\1/p' | head -n1)
fi

if [[ -z "$version" ]]; then
  echo "UNKNOWN: could not determine Chrome version"
  exit 2
fi

if version_ge "$version" "$MIN_SAFE"; then
  echo "PATCHED: $PACKAGE version $version >= $MIN_SAFE"
  exit 0
else
  echo "VULNERABLE: $PACKAGE version $version < $MIN_SAFE"
  exit 1
fi

Sources

1. GitHub Advisory Database - GHSA-v54j-r4vm-9pcv
2. NVD - CVE-2026-10953
3. Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
4. Chrome Releases - Chrome for Android Update (June 2, 2026)
5. Chromium issue tracker - issue 506147564
6. Chromium security severity guidelines
7. CISA Known Exploited Vulnerabilities Catalog
8. Chromium memory safety overview