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

CVE-2026-11080 is a use-after-free in Android WebView / Chrome on Android that affects versions prior to 149.0.7827.53. A remote attacker can deliver a crafted HTML page that triggers heap corruption when rendered in a vulnerable WebView context, which means the reachable population is Android users browsing in Chrome or inside an app that embeds WebView.

paragraph 2: The raw CVSS looks scary because it models a remote browser-memory-corruption bug with no auth required, but reality is tighter. Google’s own Chromium-facing labeling for this issue is Medium, there is no KEV listing, no public exploitation evidence, no public PoC, and the description stops at heap corruption rather than demonstrating sandbox escape or reliable code execution; that combination warrants a downgrade from the 8.8-style baseline.

Why this verdict

• UI:R is a real brake — the attacker needs the user to render hostile content, which moves this out of the wormable/server-side bucket and into phishing or malvertising territory.
• Android/WebView-only cuts exposed population — this is not your whole Chrome estate, only the Android slice plus apps that actually embed vulnerable WebView.
• The record tops out at heap corruption — there is no public claim here of sandbox escape, privilege escalation, or reliable full-device takeover from this CVE alone.
• Threat intel is cold — EPSS is tiny, there is no KEV entry, and I found no public PoC or exploitation reporting.
• Google’s own Chromium label is Medium — that is a better operational anchor than blindly inheriting an 8.8-style browser CVSS.

Why not higher?

If this had active exploitation, a public exploit, or a documented sandbox escape / device compromise chain, the score would move up fast. Right now the evidence points to a technically serious bug whose practical enterprise weaponization is still gated by user interaction, Android-only reach, and missing second-stage proof.

Why not lower?

This is still remote, no-auth, browser-facing memory corruption in a mass-deployed component. If you run a sizable managed Android fleet or have line-of-business apps embedding WebView, the reachable attack surface is real enough that this does not belong in the ignore pile.

1. Force Chrome and WebView auto-update — Use MDM/EMM policy to require automatic updates for Chrome for Android and Android System WebView. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but this is cheap hygiene and should be verified in your normal mobile compliance cycle.
2. Gate outdated Android browsers from access — If your conditional-access stack can read app or OS compliance state, block or step-up-auth devices still running pre-fix Chrome/WebView builds. There is no mitigation SLA for MEDIUM, so do this as a policy hardening improvement while you drive patch compliance inside the remediation window.
3. Prefer managed browser paths over embedded WebView — Where enterprise apps can switch from raw embedded WebView to managed browser / custom tab patterns, do it. That reduces app-specific exposure and gives you better update cadence; again, no mitigation SLA here, so fold it into app hardening rather than emergency change.
4. Keep URL filtering and Safe Browsing enforced — This bug still needs attacker HTML delivery, so mobile web filtering, DNS protections, and Safe Browsing remove a chunk of practical reach. They are not a substitute for the fix, but they are useful exposure reducers during the normal 365-day remediation window.

Run this on an auditor workstation with adb installed, against a connected Android device or a device reachable through your enterprise Android management tooling. Invoke it as ./check_cve_2026_11080.sh or ./check_cve_2026_11080.sh <device-serial>; it needs adb shell access, but not root.

#!/usr/bin/env bash
# check_cve_2026_11080.sh
# Determine whether an attached Android device is vulnerable to CVE-2026-11080
# by checking Chrome / Android WebView package versions.
#
# Output:
#   VULNERABLE - at least one relevant installed package is older than 149.0.7827.53
#   PATCHED    - relevant installed packages found and all are >= 149.0.7827.53
#   UNKNOWN    - adb/package info unavailable or no relevant package info could be read
#
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

set -u

FIXED_VERSION="149.0.7827.53"
SERIAL_ARG="${1:-}"
ADB=(adb)

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

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

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

get_version() {
  local pkg="$1"
  local out ver
  out="$(${ADB[@]} shell dumpsys package "$pkg" 2>/dev/null | tr -d '\r')" || return 1
  ver="$(printf '%s\n' "$out" | sed -n 's/.*versionName=\([^[:space:]]*\).*/\1/p' | head -n1)"
  [[ -n "$ver" ]] || return 1
  printf '%s' "$ver"
  return 0
}

if ! have_cmd adb; then
  echo "UNKNOWN - adb not installed"
  exit 2
fi

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

PACKAGES=(
  "com.android.chrome"
  "com.google.android.webview"
  "com.android.webview"
)

found_any=0
vuln_any=0
report=()

for pkg in "${PACKAGES[@]}"; do
  if ver="$(get_version "$pkg")"; then
    found_any=1
    if version_lt "$ver" "$FIXED_VERSION"; then
      vuln_any=1
      report+=("$pkg=$ver (older than $FIXED_VERSION)")
    else
      report+=("$pkg=$ver")
    fi
  fi
done

if [[ "$found_any" -eq 0 ]]; then
  echo "UNKNOWN - unable to read Chrome/WebView package versions"
  exit 2
fi

if [[ "$vuln_any" -eq 1 ]]; then
  printf 'VULNERABLE - %s\n' "${report[*]}"
  exit 1
fi

printf 'PATCHED - %s\n' "${report[*]}"
exit 0

Sources

1. NVD entry for CVE-2026-11080
2. Chrome Releases stable channel update for Desktop / Chrome 149
3. Chrome 149 release notes
4. CVE record
5. Chromium issue referenced by NVD
6. CISA Known Exploited Vulnerabilities catalog
7. FIRST EPSS API documentation
8. PCWorld coverage of Chrome 149 fixes