Insufficient policy enforcement in WebView in Google Chrome on Android prior to 149

CVE-2026-11178 is a policy bypass in Android WebView/Chrome that can let a remote attacker leak cross-origin data after a user opens a crafted page on a vulnerable Android device. The affected range is Google Chrome on Android / Android WebView prior to 149.0.7827.53, with the fix landing in the Chrome 149 stable train. In practice, this means browser sessions and app-embedded WebView sessions on Android are the exposure surface, not servers.

The vendor's MEDIUM 4.3 is basically fair on paper, but in enterprise prioritization this lands a bit lower because the attack chain is full of friction: user interaction is required, the impact is confidentiality-only and explicitly low, there is no RCE, no privilege gain, no persistence, no KEV listing, and EPSS is near the floor. The only real amplifier is that Android WebView is everywhere, so if you have sensitive SSO or internal web apps routinely used from managed Android devices, it deserves cleanup — just not emergency treatment.

Why this verdict

• Downgrade for user interaction and client-side reachability: UI:R means the attacker does not get a direct shot at the target; they need a click or equivalent user navigation into attacker content.
• Downgrade for post-condition dependence: exploitation only matters if the victim is simultaneously authenticated to a valuable origin in the same browsing environment. That implies a narrower real-world target set than the vendor score alone suggests.
• Downgrade for limited impact: the vendor vector is C:L/I:N/A:N. No code execution, no sandbox escape, no persistence, no integrity loss, no service impact.
• Downgrade for threat intel absence: no KEV listing, no cited active exploitation, and the supplied EPSS 0.00011 all push hard against urgent prioritization.
• Slight upward pressure for ubiquity: Android WebView is everywhere, including enterprise mobile apps, so this is not ignorable if your mobile fleet regularly hits SSO, SaaS, or internal portals.

Why not higher?

This is not a browser RCE, sandbox escape, auth bypass, or account-compromise primitive by itself. The chain requires user navigation plus a valuable logged-in cross-origin target, and even then the expected outcome is only limited data leakage. Without KEV, PoC traction, or stronger impact, HIGH would be inflationary.

Why not lower?

It is still a remote, no-privileges-required bug in a massively deployed mobile browsing component. For organizations with heavy Android usage, especially field staff using internal portals or SSO-backed SaaS from mobile apps, cross-origin leaks can still expose useful business data. That keeps it above IGNORE.

1. Force auto-updates for Chrome and WebView — Use MDM/Play management to keep com.android.chrome and com.google.android.webview on current builds. For a LOW verdict there is no SLA; treat as backlog hygiene and fold this into the next routine mobile browser/app update cycle.
2. Inventory mobile web usage for sensitive apps — Identify which internal and SaaS apps are commonly accessed through Android Chrome or embedded WebView, then focus validation and upgrade follow-up there first. For LOW, there is no SLA; do this as part of normal mobile exposure mapping rather than a fire drill.
3. Prefer hardened browser flows for high-value auth — Where app design allows it, push high-value authentication and sensitive workflows into managed external browser flows instead of arbitrary in-app WebViews. For LOW, treat this as architecture hardening during the next app/security review cycle.
4. Tighten identity controls on mobile sessions — Short session lifetimes, conditional access, and step-up auth reduce the resale value of whatever small amount of cross-origin data might leak. For LOW, apply only where your mobile threat model already justifies it; this is not a reason to launch disruptive controls fleet-wide.

Run this from an auditor workstation that has adb installed and connectivity to the Android device, for example ./check_cve_2026_11178.sh <device-serial>. It needs USB debugging or equivalent device shell access; no root is required, but standard adb shell access is.

#!/usr/bin/env bash
# check_cve_2026_11178.sh
# Determine whether an Android device is vulnerable to CVE-2026-11178
# by checking Chrome/WebView package versions against 149.0.7827.53.
#
# Usage:
#   ./check_cve_2026_11178.sh <device-serial>
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN / usage / connectivity problem

set -euo pipefail

FIXED_VERSION="149.0.7827.53"
SERIAL="${1:-}"

if [[ -z "$SERIAL" ]]; then
  echo "UNKNOWN - usage: $0 <device-serial>"
  exit 2
fi

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

if ! adb -s "$SERIAL" get-state >/dev/null 2>&1; then
  echo "UNKNOWN - device $SERIAL not reachable via adb"
  exit 2
fi

trim_cr() {
  tr -d '\r'
}

get_pkg_version() {
  local pkg="$1"
  adb -s "$SERIAL" shell dumpsys package "$pkg" 2>/dev/null | trim_cr | awk -F= '/versionName=/{print $2; exit}'
}

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

WEBVIEW_INFO="$(adb -s "$SERIAL" shell dumpsys webviewupdate 2>/dev/null | trim_cr || true)"
CURRENT_PROVIDER_LINE="$(printf '%s\n' "$WEBVIEW_INFO" | grep -Ei 'Current WebView package|Current WebView package \(name, version\)|currentWebViewPackage' | head -n1 || true)"

PROVIDER_PKG=""
PROVIDER_VER=""

if [[ -n "$CURRENT_PROVIDER_LINE" ]]; then
  PROVIDER_PKG="$(printf '%s\n' "$CURRENT_PROVIDER_LINE" | grep -Eo 'com\.[A-Za-z0-9._]+' | head -n1 || true)"
  PROVIDER_VER="$(printf '%s\n' "$CURRENT_PROVIDER_LINE" | grep -Eo '[0-9]+(\.[0-9]+){3,}' | head -n1 || true)"
fi

if [[ -z "$PROVIDER_PKG" ]]; then
  for candidate in com.google.android.webview com.android.chrome; do
    if ver="$(get_pkg_version "$candidate")" && [[ -n "$ver" ]]; then
      PROVIDER_PKG="$candidate"
      PROVIDER_VER="$ver"
      break
    fi
  done
fi

CHROME_VER="$(get_pkg_version com.android.chrome || true)"
WEBVIEW_VER="$(get_pkg_version com.google.android.webview || true)"

if [[ -z "$PROVIDER_VER" && -z "$CHROME_VER" && -z "$WEBVIEW_VER" ]]; then
  echo "UNKNOWN - unable to determine Chrome/WebView version"
  exit 2
fi

# Prefer the active provider when available.
CHECK_VER="$PROVIDER_VER"
CHECK_PKG="$PROVIDER_PKG"

if [[ -z "$CHECK_VER" ]]; then
  if [[ -n "$WEBVIEW_VER" ]]; then
    CHECK_VER="$WEBVIEW_VER"
    CHECK_PKG="com.google.android.webview"
  else
    CHECK_VER="$CHROME_VER"
    CHECK_PKG="com.android.chrome"
  fi
fi

if ver_ge "$CHECK_VER" "$FIXED_VERSION"; then
  echo "PATCHED - $CHECK_PKG version $CHECK_VER >= $FIXED_VERSION"
  exit 0
else
  echo "VULNERABLE - $CHECK_PKG version $CHECK_VER < $FIXED_VERSION"
  exit 1
fi

Sources

1. Google Chrome Releases - Stable Channel Update for Desktop (Chrome 149 security fixes)
2. Google Chrome Releases - Chrome for Android Update (Chrome 149 rollout start)
3. CISA Known Exploited Vulnerabilities Catalog
4. FIRST EPSS overview
5. Android Developers - Simplify your WebView implementation with Jetpack Webkit
6. Android Developers - Embedding web content into your app as primary or supporting content
7. Android Developers - Build web apps in WebView
8. SecurityWeek - Chrome 149 Patches 429 Vulnerabilities