Inappropriate implementation in Android Autofill in Google Chrome on Android prior to 149

CVE-2026-11291 is a policy bypass in Chrome on Android's Android Autofill path that lets a remote attacker use a crafted HTML page to break the expected origin boundary for autofill. Affected versions are Google Chrome on Android before the June 2, 2026 stable fix train; the desktop security baseline is 149.0.7827.53/54, and Chrome's Android stable release carrying those same fixes is 149.0.7827.59. Practically, this is about autofill binding to the wrong web context, not memory corruption or sandbox escape.

The supplied 4.3/MEDIUM baseline is still too generous for enterprise prioritization. The big downward pressure is reachability: this is Android-only, client-side, requires user interaction, and appears tied to the Android Autofill integration path rather than a wormable browser bug. That makes it a phishing/credential-misdirection problem with low blast radius, not a fleet-emergency patch.

Why this verdict

• Android-only population cut reduces reachable targets immediately versus a cross-platform Chrome bug.
• UI-required chain means the attacker must first win page delivery and then get the user to interact with autofill; that is compounding friction, not a one-packet exploit.
• Likely opt-in Android Autofill path is the biggest downgrade driver: Google documents that Chrome's Android Autofill mode for third-party services requires users to enable Autofill using another service, shrinking exposed enterprise population further.
• Impact ceiling is low by the vendor-supplied vector: C:N/I:L/A:N fits credential mis-binding or phishing assistance, not device compromise.
• No KEV and no public exploitation evidence remove the one factor that would have justified overriding the friction audit upward.

Why not higher?

There is no sign of active exploitation, no evidence of widespread public weaponization, and no path to code execution or host takeover in the disclosed impact profile. More importantly, this is not an edge-service bug: it only matters when a user on Android Chrome reaches malicious content and exercises the autofill flow.

Why not lower?

It is still a same-origin/policy bypass inside a credential-adjacent workflow, which is security-relevant even if the impact is bounded. Enterprises that standardize on Android password managers or third-party autofill could have a meaningful niche population where this bug can materially aid phishing.

1. Inventory Android Chrome versions — Identify devices with com.android.chrome below 149.0.7827.59 so you know whether this even exists in your fleet. For a LOW verdict there is no SLA beyond backlog hygiene, but you should still fold this into the next normal mobile-app hygiene sweep.
2. Restrict third-party autofill where not required — If business policy does not require third-party password managers in Chrome on Android, keep users on the default path or disable nonessential autofill integrations. This directly attacks the most important reachability condition and can be applied as normal configuration hygiene for a LOW issue.
3. Harden phishing controls for mobile web — Use Safe Browsing enforcement, secure web gateways, mobile threat defense, and identity risk signals to stop the malicious page before the browser bug is relevant. For this class of user-driven browser bug, prevention at the lure stage is more valuable than treating it like a perimeter emergency.
4. Watch for anomalous credential use — Because likely abuse ends in credential submission, focus on impossible-travel, unfamiliar-device, and risky-sign-in detections rather than trying to signature the CVE itself. Keep this in your normal identity-defense program; again, LOW means backlog hygiene, not incident-level urgency.

Run this from an auditor workstation with adb installed against a USB- or network-connected Android device. Invoke it as ./check_cve_2026_11291.sh or ./check_cve_2026_11291.sh <device-serial>; it needs ADB access to the target device but no root, and checks whether installed Chrome is below the Android fixed build 149.0.7827.59.

#!/usr/bin/env bash
# check_cve_2026_11291.sh
# Purpose: Check whether Chrome on Android is vulnerable to CVE-2026-11291
# Logic: Vulnerable if com.android.chrome version is lower than 149.0.7827.59
# 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

command -v adb >/dev/null 2>&1 || { echo "UNKNOWN: adb not found in PATH"; exit 2; }

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

raw_version=$("${ADB[@]}" shell dumpsys package "$PKG" 2>/dev/null | tr -d '\r' | grep -m1 'versionName=' || true)

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

version="${raw_version#*=}"
version="${version%% *}"

norm_ver() {
  local IFS=.
  local v="$1"
  local a b c d
  read -r a b c d <<< "$v"
  a=${a:-0}; b=${b:-0}; c=${c:-0}; d=${d:-0}
  printf "%05d%05d%05d%05d\n" "$a" "$b" "$c" "$d"
}

installed_n=$(norm_ver "$version")
fixed_n=$(norm_ver "$FIXED")

if [[ "$installed_n" < "$fixed_n" ]]; then
  echo "VULNERABLE: $PKG version $version is lower than fixed $FIXED"
  exit 1
fi

if [[ "$installed_n" >= "$fixed_n" ]]; then
  echo "PATCHED: $PKG version $version is at or above fixed $FIXED"
  exit 0
fi

echo "UNKNOWN: unable to compare versions (installed=$version fixed=$FIXED)"
exit 2

Sources

1. NVD CVE-2026-11291
2. Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
3. Chrome Releases - Chrome for Android Update (June 2, 2026)
4. Android Developers - Build autofill services
5. Android Developers Blog - Timeline update: third-party autofill services support on Chrome on Android
6. Chrome for Developers - Shared autofill across iframes: an initial proposal
7. FIRST EPSS overview
8. CISA Known Exploited Vulnerabilities Catalog