Integer overflow in WebView in Google Chrome on Android prior to 149

CVE-2026-11290 is an integer overflow in Android WebView/Chromium code affecting Google Chrome on Android prior to 149.0.7827.53. The stated impact is local denial of service via a malicious file, which means the attacker needs code or app-level presence on the device and then has to drive the vulnerable WebView path with crafted local content.

The vendor's MEDIUM label is generous for enterprise triage. In real deployments this is post-initial-access, single-device, and availability-only: no remote code execution, no privilege escalation, no cross-device worm path, and no evidence of in-the-wild exploitation or KEV inclusion as of the June 5, 2026 disclosure window.

Why this verdict

• Requires local attacker position: AV:L means the attacker is already on the device, which implies a prior compromise stage or malicious app install.
• Requires low privileges and user interaction: PR:L + UI:R compounds the friction. This is not unauthenticated remote drive-by reach.
• Impact is availability-only: the CVSS vector and description point to DoS, not code execution, data theft, or privilege escalation.
• Blast radius is narrow: practical impact is one Android handset or one embedded WebView consumer, not a server farm or desktop fleet-wide worm path.
• No exploitation pressure: no KEV listing, no campaign reporting, and a near-zero EPSS score remove the usual urgency amplifiers.

Why not higher?

A higher rating would need at least one strong amplifier: remote reach, reliable code execution, privilege gain, broad external exposure, or active exploitation. This CVE has none of those. It starts from an already-on-device attacker and ends at a crash.

Why not lower?

It is still a real memory-safety flaw in a ubiquitous component and the affected software is widely present on Android devices. If your org depends heavily on managed Android endpoints, app crashes in business workflows are still worth fixing, just not worth dropping everything for.

1. Enforce Play/MDM update compliance — Push WebView/Chrome updates through managed Google Play or your Android EMM so devices move to 149.0.7827.53 or later. For a LOW verdict there is no formal noisgate mitigation SLA; treat this as backlog hygiene and fold it into the next normal mobile app-update wave.
2. Block sideloading and unknown sources — The exploit path needs local attacker presence, so reducing malicious app installation is the best compensating control. Enforce this continuously via Android Enterprise restrictions; for this LOW item, do it as part of baseline hardening rather than an emergency project.
3. Restrict risky file-open paths — If you control line-of-business apps using embedded WebView, reduce automatic handling of untrusted local files and document viewers where feasible. Apply during the normal secure-mobile backlog cycle because the issue is local and availability-only.
4. Watch for mobile crash clusters — Use MDM, app telemetry, or mobile threat defense to spot repeated WebView or app crashes on vulnerable builds. This will not prevent exploitation, but it gives you early confirmation if the bug starts showing up operationally before patch coverage completes.

Run this from an auditor workstation with adb installed and a managed Android device connected over USB or approved network debugging. Invoke it as ./check_webview_cve_2026_11290.sh <device-serial> or ./check_webview_cve_2026_11290.sh for the only attached device; no root is required, but adb access to the device is.

#!/usr/bin/env bash
# check_webview_cve_2026_11290.sh
# Determine whether an attached Android device is vulnerable to CVE-2026-11290
# Checks the active WebView provider when possible, otherwise falls back to common packages.
# Outputs one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

FIXED_VERSION="149.0.7827.53"
SERIAL="${1:-}"
ADB=(adb)
if [ -n "$SERIAL" ]; then
  ADB+=( -s "$SERIAL" )
fi

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

version_ge() {
  # returns 0 if $1 >= $2
  [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | tail -n1)" = "$1" ]
}

get_prop() {
  "${ADB[@]}" shell getprop "$1" 2>/dev/null | tr -d '\r'
}

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

get_current_webview_provider() {
  local out pkg
  out=$("${ADB[@]}" shell cmd webviewupdate getCurrentWebViewPackage 2>/dev/null | tr -d '\r') || true
  pkg=$(printf '%s\n' "$out" | sed -n 's/.*Current WebView package (name, version): \([^,]*\),.*/\1/p' | head -n1)
  if [ -n "$pkg" ]; then
    echo "$pkg"
    return 0
  fi
  return 1
}

# Basic adb sanity
STATE=$("${ADB[@]}" get-state 2>/dev/null | tr -d '\r')
[ "$STATE" = "device" ] || fail_unknown "adb device not available"

MODEL=$(get_prop ro.product.model)
ANDROID=$(get_prop ro.build.version.release)

PKG=""
VER=""

if PKG=$(get_current_webview_provider); then
  VER=$(get_pkg_version "$PKG") || true
fi

# Fallbacks for devices where cmd webviewupdate is unavailable or restricted
if [ -z "$PKG" ] || [ -z "$VER" ]; then
  for CANDIDATE in com.google.android.webview com.android.chrome; do
    V=$(get_pkg_version "$CANDIDATE") || true
    if [ -n "$V" ]; then
      PKG="$CANDIDATE"
      VER="$V"
      break
    fi
  done
fi

if [ -z "$PKG" ] || [ -z "$VER" ]; then
  fail_unknown "could not determine active WebView/Chrome package version"
fi

if version_ge "$VER" "$FIXED_VERSION"; then
  echo "PATCHED - model=$MODEL android=$ANDROID package=$PKG version=$VER fixed_floor=$FIXED_VERSION"
  exit 0
else
  echo "VULNERABLE - model=$MODEL android=$ANDROID package=$PKG version=$VER fixed_floor=$FIXED_VERSION"
  exit 1
fi

Sources

1. NVD entry
2. CVE.org record
3. VulDB CVE page
4. Chrome Enterprise previous release notes
5. Android Developers: Build web apps in WebView
6. Android System WebView on Google Play
7. CISA Known Exploited Vulnerabilities Catalog
8. FIRST EPSS overview