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

Based on the published description, CVE-2026-11012 is a use-after-free in the Serial implementation of Google Chrome on Android affecting versions before 149.0.7827.53. The important clause is the one defenders should not skip: the attacker must have already compromised the renderer process. That makes this a second-stage browser exploit primitive inside a chain, not a stand-alone malicious-page bug that any random phishing link can cash out by itself.

That changes the patching story materially. In pure technical terms, memory corruption inside a browser component is always scary, and Chrome escapes are prized by serious operators. In operational reality for a 10,000-device fleet, this lands lower because it is Android-only, Chrome-version-bounded, and post-renderer-compromise with no KEV listing, no public exploitation evidence, and a very low EPSS value in the intel provided. Treat it as a meaningful mobile hardening item, not an emergency fleet-wide incident.

Why this verdict

• Requires prior renderer compromise — this is the biggest friction point and the main reason it does not belong in HIGH or CRITICAL for most fleets
• Android-only and version-bounded — only Chrome on Android below 149.0.7827.53 is in scope, which narrows exposure compared with cross-platform Chrome bugs
• No KEV, no public exploitation evidence, and EPSS 0.00035 — the present threat signal is weak, so urgency should come from asset exposure and user tiering, not hype
• Client-side blast radius is per user/device — even successful use usually starts with one endpoint and still needs follow-on actions for estate-level damage
• Modern enterprise controls still help after the exploit — MFA, conditional access, work-profile isolation, token controls, and mobile telemetry all reduce payoff

Why not higher?

This is not described as a one-bug remote compromise from a malicious page. The prerequisite of an already-compromised renderer means the attacker needs another exploit stage first, which sharply reduces both reachable population and opportunistic abuse potential.

Why not lower?

Do not ignore Chrome sandbox-adjacent memory corruption just because the chain is narrow. Browser exploit brokers and targeted operators care a lot about second-stage primitives on mobile, and Chrome on Android is common enough that affected high-risk users still deserve attention.

1. Force Chrome version inventory now — Use your EMM/MDM to identify Android devices running com.android.chrome below 149.0.7827.53 and tag high-risk users first. There is no mitigation SLA for MEDIUM; use this immediately for scoping, then remediate within the 365-day window.
2. Keep users on Stable only — Remove unmanaged Beta/Dev browser channels from the managed fleet where policy allows, because exploit reliability is easier when browser drift is high. There is no mitigation SLA for MEDIUM; enforce channel hygiene during normal mobile platform hardening and complete remediation within 365 days.
3. Prioritize high-risk Android cohorts — Move executives, admins, incident responders, developers with production access, and travel-heavy users to the front of the queue because targeted mobile chains concentrate there. There is no mitigation SLA for MEDIUM; use risk-tiering to accelerate patch uptake while still working inside the 365-day remediation window.
4. Watch Chrome crash and abuse telemetry — Monitor com.android.chrome crash spikes, device-risk alerts, suspicious OAuth/token reuse, and anomalous SaaS logins tied to Android users. This will not prevent exploitation, but it gives you a practical backstop while rollout completes within the 365-day remediation window.

Run this from an auditor workstation with Android Platform Tools (adb) installed, against a USB-connected or otherwise reachable managed Android device. Invoke it as ./check_chrome_android_cve_2026_11012.sh for one attached device or ./check_chrome_android_cve_2026_11012.sh <device-serial> for a specific device; no root is required, but you do need adb access and permission to query package metadata.

#!/usr/bin/env bash
# check_chrome_android_cve_2026_11012.sh
# Defensive validation for CVE-2026-11012 on Chrome for Android.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

PKG="com.android.chrome"
FIXED="149.0.7827.53"
SERIAL_ARG="${1:-}"

fail_unknown() {
  echo "UNKNOWN: $1"
  exit 2
}

version_lt() {
  # Returns 0 if $1 < $2, else 1
  local IFS=.
  local i
  local -a a=($1) b=($2)
  local len=${#a[@]}
  if [ ${#b[@]} -gt $len ]; then len=${#b[@]}; fi
  for ((i=0; i<len; i++)); do
    local ai=${a[i]:-0}
    local bi=${b[i]:-0}
    ai=${ai//[^0-9]/}
    bi=${bi//[^0-9]/}
    ai=${ai:-0}
    bi=${bi:-0}
    if ((10#$ai < 10#$bi)); then
      return 0
    elif ((10#$ai > 10#$bi)); then
      return 1
    fi
  done
  return 1
}

command -v adb >/dev/null 2>&1 || fail_unknown "adb not found in PATH"

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

STATE="$(${ADB[@]} get-state 2>/dev/null || true)"
[ "$STATE" = "device" ] || fail_unknown "no reachable adb device"

PKG_INFO="$(${ADB[@]} shell dumpsys package "$PKG" 2>/dev/null || true)"
[ -n "$PKG_INFO" ] || fail_unknown "$PKG not installed or package query failed"

VERSION_NAME="$(printf '%s
' "$PKG_INFO" | sed -n 's/.*versionName=\([^[:space:]]*\).*/\1/p' | head -n1)"
[ -n "$VERSION_NAME" ] || fail_unknown "could not determine Chrome version"

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

Sources

1. Chrome Releases homepage
2. Chrome early stable desktop 149.0.7827.53/.54
3. Chrome beta desktop 149.0.7827.53
4. Chrome 148 beta for Android adds Web Serial
5. CISA Known Exploited Vulnerabilities Catalog
6. FIRST EPSS overview
7. FIRST EPSS API documentation