Insufficient validation of untrusted input in WebView in Google Chrome on Android prior to 149

CVE-2026-11007 is an input-validation flaw in WebView affecting Google Chrome on Android / Android System WebView before the June 2026 fixed builds. Public descriptions tie it to cross-origin data access via a crafted HTML page, but with a crucial catch: the attacker must already have access to the renderer process. In practical terms, that means this bug is not the initial browser break; it is a same-device, post-renderer-compromise boundary bypass that can expose data from other origins rendered inside the vulnerable WebView context.

Reality is lower than what the phrase *remote attacker* suggests. The meaningful prerequisite is renderer-process compromise first, which implies either a separate browser/WebView exploit or an already-compromised app/device path. That sharply narrows the reachable population and turns this into an exploit-chain amplifier, not a standalone fleet-wide emergency. Still, WebView is everywhere on Android and cross-origin data theft can expose tokens, session state, and embedded-app content, so this is not backlog junk either.

Why this verdict

• Downward adjustment: requires renderer compromise first — this is not unauthenticated remote code execution from a clean start; it presumes a prior exploit stage inside Chrome/WebView.
• Downward adjustment: client-side reach, not edge exposure — attackers cannot sweep the internet for this like they can with VPNs, gateways, or web apps.
• Upward adjustment: huge deployment footprint — Android WebView and Chrome are everywhere, so vulnerable versions will exist in large numbers across mobile fleets.
• Upward adjustment: cross-origin data access matters — if chained successfully, the bug can expose authenticated content and session material inside embedded enterprise app flows.
• Downward adjustment: no KEV, no public exploitation, tiny EPSS — current threat intelligence does not show this bug being weaponized at scale.

Why not higher?

Because the attacker does not get to start here. The prerequisite of renderer-process access is a compounding friction point that implies another exploit, another failure, or an already-compromised context before CVE-2026-11007 becomes useful. Also, the public impact described is data access within the rendering boundary, not direct sandbox escape, OS compromise, or broad wormable behavior.

Why not lower?

Because this is still a security boundary failure in WebView, not a harmless crash. Cross-origin data exposure inside mobile app/browser sessions can translate into real token theft and sensitive content access when paired with the right app workflow. On large Android estates, chainable browser/WebView flaws deserve disciplined patching even when they are not front-door bugs.

1. Force-update Chrome and WebView — Use your EMM/MDM and managed Google Play controls to push Chrome for Android 149.0.7827.59+ and Android System WebView 149.0.7827.53+ across enrolled devices. For a MEDIUM verdict there is no noisgate mitigation SLA; this is the primary remediation path and should be completed inside the 365-day remediation window, though mobile-browser components should realistically move much faster.
2. Block unmanaged Android versions from sensitive apps — Enforce conditional access or app protection policy so devices missing current Chrome/WebView builds cannot reach high-value SSO, mail, HR, and finance applications. This reduces exposure while updates propagate; for MEDIUM, there is no mitigation SLA — go straight to the 365-day remediation window unless your internal mobile hardening standard is stricter.
3. Constrain risky WebView content flows — For internally developed Android apps, reduce arbitrary external content loading in WebView, prefer verified domains, and avoid keeping high-value sessions inside embedded web flows longer than needed. This does not remove the bug, but it cuts the amount of valuable cross-origin data present if exploitation occurs during the remediation window.
4. Prioritize devices with sensitive mobile SSO — Patch executive, privileged-admin, BYOD-with-corporate-access, and kiosk/shared-device populations first because those devices are more likely to carry reusable tokens and authenticated sessions. Even for a MEDIUM issue, threat reduction is better when you start with the highest-value identities rather than trying to boil the ocean.

Run this from an auditor workstation with adb installed against a connected Android device, or adapt the package/version logic into your EMM compliance checks. Invoke it as ./check_cve_2026_11007.sh <device-serial> or omit the serial for a single attached device; no root is required, but the device must allow adb shell access.

#!/usr/bin/env bash
# check_cve_2026_11007.sh
# Validate Chrome for Android / Android System WebView versions for CVE-2026-11007
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN / error

set -u

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

FIX_CHROME="149.0.7827.59"
FIX_WEBVIEW="149.0.7827.53"

log() { echo "[+] $*"; }
err() { echo "[!] $*" >&2; }

have_adb() {
  command -v adb >/dev/null 2>&1
}

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

pkg_version() {
  local pkg="$1"
  "${ADB[@]}" shell dumpsys package "$pkg" 2>/dev/null | tr -d '\r' | awk -F= '/versionName=/{print $2; exit}'
}

pkg_installed() {
  local pkg="$1"
  "${ADB[@]}" shell pm path "$pkg" 2>/dev/null | grep -q '^package:'
}

if ! have_adb; then
  err "adb not found in PATH"
  echo "UNKNOWN"
  exit 2
fi

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

status="PATCHED"
vuln_reasons=()
seen_any=0

# Chrome for Android
if pkg_installed com.android.chrome; then
  seen_any=1
  chrome_ver="$(pkg_version com.android.chrome)"
  if [[ -z "$chrome_ver" ]]; then
    err "could not read Chrome version"
    echo "UNKNOWN"
    exit 2
  fi
  log "Chrome version: $chrome_ver"
  if version_lt "$chrome_ver" "$FIX_CHROME"; then
    status="VULNERABLE"
    vuln_reasons+=("Chrome $chrome_ver < $FIX_CHROME")
  fi
fi

# Android System WebView (Google package)
if pkg_installed com.google.android.webview; then
  seen_any=1
  webview_ver="$(pkg_version com.google.android.webview)"
  if [[ -z "$webview_ver" ]]; then
    err "could not read Google WebView version"
    echo "UNKNOWN"
    exit 2
  fi
  log "Google WebView version: $webview_ver"
  if version_lt "$webview_ver" "$FIX_WEBVIEW"; then
    status="VULNERABLE"
    vuln_reasons+=("Google WebView $webview_ver < $FIX_WEBVIEW")
  fi
fi

# AOSP WebView fallback package
if pkg_installed com.android.webview; then
  seen_any=1
  aosp_webview_ver="$(pkg_version com.android.webview)"
  if [[ -z "$aosp_webview_ver" ]]; then
    err "could not read AOSP WebView version"
    echo "UNKNOWN"
    exit 2
  fi
  log "AOSP WebView version: $aosp_webview_ver"
  if version_lt "$aosp_webview_ver" "$FIX_WEBVIEW"; then
    status="VULNERABLE"
    vuln_reasons+=("AOSP WebView $aosp_webview_ver < $FIX_WEBVIEW")
  fi
fi

if [[ "$seen_any" -eq 0 ]]; then
  err "neither Chrome nor WebView packages were found"
  echo "UNKNOWN"
  exit 2
fi

if [[ "$status" == "VULNERABLE" ]]; then
  echo "VULNERABLE"
  printf '%s\n' "Reasons: ${vuln_reasons[*]}"
  exit 1
fi

echo "PATCHED"
exit 0

Sources

1. Chrome Releases: Chrome for Android Update (June 2, 2026)
2. Chrome Releases: Stable Channel Update for Desktop (June 2, 2026)
3. Chromium Chrome 149 release notes entry showing CVE-2026-11007 as Medium
4. Chromium Security
5. Chromium Severity Guidelines for Security Issues
6. CISA Known Exploited Vulnerabilities Catalog
7. Google Play: Android System WebView
8. Google Play: Google Chrome