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

CVE-2026-11188 is a use-after-free in Chrome's USB handling on Android. The affected population is Chrome on Android before the June 2, 2026 Android stable release carrying 149.0.7827.59, which Google says contains the same security fixes as the corresponding desktop 149.0.7827.53/54 release where this CVE is listed as Medium severity; the bug is described as a remote attacker potentially achieving a sandbox escape via a crafted HTML page.

The raw 8.8 CVSS framing overshoots the real enterprise risk. In practice this is Android-only, not a broad desktop/browser fleet issue, and exploitation appears to sit behind WebUSB-style user/device interaction plus the normal difficulty of turning a memory bug into a reliable sandbox escape on modern Android Chrome. Chrome's own advisory calling it Medium lines up better with the reachable population than the generic ADP-style 8.8.

Why this verdict

• Start at 8.8, then cut for platform reach: the baseline assumes a generic network-reachable browser target, but this bug is scoped to Chrome on Android, not the full Chrome estate.
• Cut again for prerequisite stacking: exploitation likely requires attacker content + user browsing + USB/OTG presence + device permission flow. Each prerequisite compounds downward pressure because it narrows the reachable population.
• Chrome itself calls it Medium: the vendor advisory lists CVE-2026-11188 as Medium, which is more persuasive here than a generic high-impact CVSS overlay.
• No active exploitation signal: not KEV-listed, no public PoC found, and EPSS 0.00068 all argue against emergency-tier prioritization.
• Blast radius is endpoint-local: even if exploited, this is an attack on an individual Android browser instance, not a wormable or unauthenticated server-side fleet event.

Why not higher?

This is not a clean, mass-reachable drive-by RCE against the general enterprise browser fleet. The path appears to require Android, a malicious browsing event, and likely USB/device interaction plus consent, which is a far cry from 'internet attacker can hit every host now.'

Why not lower?

Do not dismiss it as noise. A browser sandbox escape is still a meaningful end-state on a mobile endpoint, and enterprises with Android devices used alongside peripherals, kiosks, scanners, or field hardware have a more realistic exposure path than office-only users.

1. Restrict USB access in Chrome policy — Use Chrome Enterprise and device-management controls to block or tightly limit site access to USB devices for Android cohorts that do not need it. For a MEDIUM noisgate verdict there is no mitigation SLA; use this selectively for higher-risk mobile groups while you work the remediation window.
2. Limit OTG/peripheral use on managed Android — If your MDM/UEM supports it, reduce or prohibit unneeded USB peripheral / OTG workflows on corporate Android devices. This directly removes the most important prerequisite in the attack chain; there is no mitigation SLA for MEDIUM, so apply where business impact is low and exposure is highest.
3. Prioritize field and kiosk-adjacent users — Focus validation and communication on users who actually connect Android phones/tablets to readers, scanners, industrial gear, or debug accessories. They are the minority slice where this CVE is operationally plausible, and for MEDIUM there is no mitigation SLA — go straight to the remediation window unless local risk justifies temporary restrictions.

Run this from an auditor workstation with adb installed against a managed Android device that has USB debugging or enterprise shell access enabled. Invoke it as ./check_cve_2026_11188.sh <device-serial> or without an argument for the only attached device; no root is required, but you do need permission to query package metadata on the target.

#!/usr/bin/env bash
# check_cve_2026_11188.sh
# Verifies whether Chrome on an attached Android device is vulnerable to CVE-2026-11188.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

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

adb_cmd() {
  if [[ -n "$SERIAL" ]]; then
    adb -s "$SERIAL" "$@"
  else
    adb "$@"
  fi
}

version_lt() {
  # returns 0 if $1 < $2
  local IFS=.
  local i
  local -a va=($1) vb=($2)
  local len=${#va[@]}
  if (( ${#vb[@]} > len )); then len=${#vb[@]}; fi
  for ((i=0; i<len; i++)); do
    local a=${va[i]:-0}
    local b=${vb[i]:-0}
    if ((10#$a < 10#$b)); then
      return 0
    elif ((10#$a > 10#$b)); then
      return 1
    fi
  done
  return 1
}

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

STATE=$(adb_cmd get-state 2>/dev/null || true)
if [[ "$STATE" != "device" ]]; then
  echo "UNKNOWN - no reachable Android device via adb"
  exit 2
fi

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

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

if version_lt "$VERSION" "$FIXED"; then
  echo "VULNERABLE - $PKG version $VERSION is older than fixed version $FIXED"
  exit 1
else
  echo "PATCHED - $PKG version $VERSION is at or newer than fixed version $FIXED"
  exit 0
fi

Sources

1. Google Chrome Releases - Stable Channel Update for Desktop (lists CVE-2026-11188 as Medium)
2. Google Chrome Releases - Chrome for Android Update (149.0.7827.59)
3. Google Chrome Help - Connect a website to a USB, Serial, or HID device
4. CISA Known Exploited Vulnerabilities Catalog
5. FIRST EPSS API documentation
6. NVD - CVE-2025-3620 (historical analogous Chrome USB use-after-free with ADP 8.8)
7. Chromium issue 502959826 for CVE-2026-11188 (restricted bug tracker entry)
8. CVE Alert aggregator entry for CVE-2026-11188