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

CVE-2026-10934 is a use-after-free in Chrome Autofill on Android affecting versions before 149.0.7827.53. In plain English: memory tied to Autofill handling can be reused after it should be dead, which creates a path for controlled memory corruption. The key caveat is baked into Google's own description: the attacker must already have compromised the renderer process and still needs user interaction on a crafted page, so this is not a one-bug drive-by RCE story.

Google's HIGH 8.3 score is technically defensible in a lab because browser-process memory corruption can be a serious privilege step-up from renderer code execution. In enterprise reality, that baseline is too hot: this bug is Android-only, high-complexity, user-interaction-required, and explicitly post-initial-browser-compromise. That makes it valuable to exploit developers building a Chrome chain, but a weaker patching priority than unauthenticated single-bug remote compromises.

Why this verdict

• Major downward pressure: requires prior renderer compromise. That implies the attacker has already landed an earlier browser exploit stage, which is a huge real-world filter and makes this a chain component, not an entry bug.
• Android-only scope trims enterprise exposure. Many 10,000-host environments care far more about Windows/macOS browser exposure than a mobile-only Chrome issue, especially when mobile browsing is partly segmented by MDM and app controls.
• High complexity plus user interaction cuts scalability. Even after initial renderer control, the attacker still needs a reliable Autofill trigger path and user-driven conditions, which is a bad recipe for broad opportunistic exploitation.
• No KEV and near-zero EPSS remove urgency amplification. There is no public signal that attackers are actively preferring this bug right now.
• Still not LOW because browser-process compromise matters. If an actor already has renderer execution, a browser-side memory corruption bug on a ubiquitous app is exactly the kind of second-stage primitive that can turn a crash chain into session theft or broader app compromise.

Why not higher?

Because this bug assumes too much. An unauthenticated remote attacker cannot just throw a link at your fleet and win with CVE-2026-10934 alone; they need a separate renderer compromise first, then a reliable second-stage exploit path, then user interaction. That's multiple compounding friction points, and each one narrows the real exposed population.

Why not lower?

Because post-renderer Chrome exploitation is still operationally valuable. If an attacker already has renderer control, stepping into a more privileged browser context on a widely deployed mobile browser can materially increase data access and persistence inside the app. That keeps it above backlog-only hygiene.

1. Enforce Chrome auto-update through MDM — Make sure managed Android devices are actually pulling 149.0.7827.53+ from Google Play and not sitting on deferred app updates. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but this control reduces long-tail exposure while rollout completes.
2. Prioritize high-risk Android cohorts — Move shared-admin, executive, and research users to the front of the app-update queue because they are the most plausible targets for browser exploit chains. Again, no mitigation SLA applies at MEDIUM, so use this as risk-based scoping while you complete remediation inside the 365-day window.
3. Reduce untrusted mobile browsing where feasible — Use MDM/browser policy to steer users away from unmanaged sideloaded browsers and high-risk browsing patterns on managed devices. This does not replace patching, but it reduces the chances of the attacker ever landing the required first-stage renderer compromise.
4. Watch for Chrome crash outliers on Android — Correlate repeated Chrome crashes, forced restarts, and suspicious account/session reuse from mobile devices with version data from MDM. That will not catch exploitation cleanly, but it is one of the few practical interim signals for a browser memory-corruption chain.

Run this on an auditor workstation with adb installed and a managed Android device connected over USB or authorized wireless debugging. Invoke it as ./check_chrome_android_cve_2026_10934.sh or ./check_chrome_android_cve_2026_10934.sh <serial>; it needs no root on the device, only adb shell access to read package metadata.

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

set -u

TARGET_SERIAL="${1:-}"
ADB_BASE=(adb)
if [[ -n "$TARGET_SERIAL" ]]; then
  ADB_BASE+=( -s "$TARGET_SERIAL" )
fi

pkg="com.android.chrome"
fixed_version="149.0.7827.53"

have_cmd() {
  command -v "$1" >/dev/null 2>&1
}

version_lt() {
  # returns 0 if $1 < $2
  local a="$1" b="$2"
  local first
  first=$(printf '%s\n%s\n' "$a" "$b" | sort -V | head -n1)
  [[ "$a" != "$b" && "$first" == "$a" ]]
}

if ! have_cmd adb; then
  echo "UNKNOWN: adb not found in PATH"
  exit 2
fi

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

# Try dumpsys first; fall back to cmd package.
version=$(
  "${ADB_BASE[@]}" shell dumpsys package "$pkg" 2>/dev/null | awk -F= '/versionName=/{print $2; exit}' | tr -d '\r'
)

if [[ -z "$version" ]]; then
  version=$(
    "${ADB_BASE[@]}" shell cmd package dump "$pkg" 2>/dev/null | awk -F= '/versionName=/{print $2; exit}' | tr -d '\r'
  )
fi

if [[ -z "$version" ]]; then
  echo "UNKNOWN: unable to read Chrome version for package $pkg"
  exit 2
fi

# Normalize possible suffixes like -beta or whitespace.
version=$(echo "$version" | awk '{print $1}')

if version_lt "$version" "$fixed_version"; then
  echo "VULNERABLE: $pkg version $version is below fixed version $fixed_version"
  exit 1
else
  echo "PATCHED: $pkg version $version is at or above fixed version $fixed_version"
  exit 0
fi

Sources

1. Chrome Releases: Chrome for Android Update (May 28, 2026)
2. Chrome Releases: Early Stable Update for Desktop (May 29, 2026)
3. Chromium source: Android Autofill README
4. Google Play: Google Chrome on Android
5. CISA Known Exploited Vulnerabilities Catalog
6. FIRST EPSS API documentation
7. FIRST EPSS data and statistics
8. Google Chrome update guidance