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

CVE-2026-10932 is a use-after-free in Chrome UI affecting Google Chrome on Android before the fixed 149 branch security release. Google’s June 2, 2026 Android stable note shipped Chrome 149.0.7827.59 and explicitly says Android carries the same security fixes as the corresponding desktop 149.0.7827.53/54 release, where CVE-2026-10932 is listed as a High severity bug. Practically, your Android exposure is devices still running older Chrome for Android builds, especially pre-149 stable or lagging 149 builds that have not yet picked up the Android rollout.

The vendor’s 8.8/HIGH score is technically defensible for a memory-corruption browser bug, but it overstates the patch urgency for most enterprises. This is Android-only, requires user interaction, has no KEV listing, no public in-the-wild evidence located, and a very low EPSS. The biggest real-world downgrade is attacker reach: this is not an internet-facing server bug, not wormable, and not a one-packet takeover; it is a client-side browser exploit that still needs a user to hit the page and an exploit chain reliable enough to survive Chrome’s sandboxing and Android-specific process isolation.

Why this verdict

• Downgrade for attacker position: the attacker is *unauthenticated remote*, but only if they can first get a user onto hostile web content; that is a prior delivery problem, not direct service reach.
• Downgrade for exposure population: this is Chrome on Android, not cross-platform Chrome desktop, so the reachable enterprise population is narrower from the start.
• Downgrade for chain complexity: a use-after-free gives memory corruption, but reliable exploitation on Android still needs device/build-specific stabilization beyond just making Chrome crash.
• Downgrade for blast radius controls: Chrome on Android uses sandboxed helper processes, and site isolation is partial or fuller depending on device RAM and configuration, which constrains cross-site payoff on many devices.
• Downgrade for threat intel: no KEV, no public PoC found, and EPSS 0.00068 all argue against immediate mass exploitation pressure.

Why not higher?

This is not a direct-to-service RCE that every external scanner can find and every botnet can hit. The attack requires a victim browsing event, a vulnerable Android Chrome build, and a stable exploit chain that survives modern browser and Android mitigations; that combination is exactly why it does not earn a noisgate HIGH or CRITICAL.

Why not lower?

It is still a real browser memory-safety bug in a massively deployed client, and successful exploitation can expose authenticated web sessions and sensitive rendered content. If you have a large managed Android fleet with executives, admins, or high-risk mobile users, the consequence side is serious enough that this should not be thrown into backlog hygiene.

1. Enforce managed Chrome updates — Push Chrome through Managed Google Play / EMM and verify devices are actually receiving current stable builds. For this MEDIUM verdict there is no noisgate mitigation SLA; use this as an operational control while you drive toward the 365-day remediation window.
2. Inventory Android Chrome versions centrally — Do not rely on perimeter scanners; pull package-version data from your MDM/EMM and flag Chrome for Android < 149.0.7827.59. Again, no mitigation SLA — go straight to the remediation program, but close visibility gaps now because mobile app patch lag is usually the real problem.
3. Reduce unmanaged browsing risk for high-value users — For execs, admins, and privileged mobile users, restrict sideloading, keep Safe Browsing enabled, and prefer managed work-profile browsing paths. This does not replace patching, but it lowers the odds of step 1 succeeding while you complete remediation inside the 365-day window.
4. Monitor for suspicious mobile session reuse — Because browser exploitation often cashes out as session theft rather than loud malware, watch IdP, mail, and SaaS logs for anomalous token use from Android users. There is no mitigation SLA on a MEDIUM call, but this is a cheap way to catch business impact if exploitation does occur before remediation.

Run this from an auditor workstation with adb installed against a USB- or network-connected Android device. Example: ./check_chrome_android_cve_2026_10932.sh ABC123DEF or, if only one device is connected, ./check_chrome_android_cve_2026_10932.sh. It needs adb shell access to query the package manager; no root is required.

#!/usr/bin/env bash
# check_chrome_android_cve_2026_10932.sh
# Detect whether Google Chrome on Android is patched for CVE-2026-10932.
# Logic: Chrome for Android 149.0.7827.59 contains the same security fixes as
# desktop 149.0.7827.53/54, where CVE-2026-10932 is listed.
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

set -u

PKG="com.android.chrome"
FIXED="149.0.7827.59"
SERIAL="${1:-}"
ADB=(adb)

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

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

if ! "${ADB[@]}" get-state >/dev/null 2>&1; then
  echo "UNKNOWN: adb cannot reach the target device"
  exit 2
fi

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

if [[ -z "$VERSION" ]]; then
  VERSION=$("${ADB[@]}" shell cmd package list packages -f "$PKG" 2>/dev/null | tr -d '\r' >/dev/null; \
            "${ADB[@]}" shell dumpsys package "$PKG" 2>/dev/null | tr -d '\r' | grep -m1 'versionName=' | cut -d= -f2)
fi

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

CUR=$(ver_to_int "$VERSION")
MIN=$(ver_to_int "$FIXED")

if [[ "$CUR" -ge "$MIN" ]]; then
  echo "PATCHED: $PKG version $VERSION >= $FIXED"
  exit 0
else
  echo "VULNERABLE: $PKG version $VERSION < $FIXED"
  exit 1
fi

Sources

1. Chrome for Android Update - June 2, 2026
2. Chrome Stable Channel Update for Desktop - June 2, 2026
3. Chromium Security
4. Chromium Site Isolation overview
5. Chromium process model and site isolation documentation
6. Chrome Android Sandbox Design
7. CISA Known Exploited Vulnerabilities Catalog
8. Android Enterprise - Access to Managed Google Play