Inappropriate implementation in WebView in Google Chrome on Android prior to 149

CVE-2026-11097 is a WebView cross-origin data leak in Google Chrome on Android affecting builds prior to 149.0.7827.53. The bug class is confidentiality-only: a remote attacker can use a crafted HTML page to read data that should stay isolated by the browser's origin boundaries, but only inside the vulnerable Android browsing/WebView context. There is no code execution, no sandbox escape, and no direct server-side foothold here.

Google's MEDIUM 6.5 is technically fair in a lab, but it overstates enterprise urgency. The real-world chain needs an Android user to load attacker content in Chrome or an app-backed WebView, then have valuable cross-origin data present in that same context; that sharply narrows population, blast radius, and operational payoff compared with remotely exploitable server or desktop-browser RCE bugs.

Why this verdict

• Downgrade from 6.5 for attacker position: the bug is *unauthenticated remote* on paper, but it still requires the victim to open malicious content on Android. That user-action prerequisite is real friction at fleet scale.
• Downgrade for exposure population: this is not an internet-facing server flaw. It only matters on Android devices running vulnerable Chrome/WebView, and only where users hit the vulnerable content path.
• Downgrade for blast radius: impact is confidentiality-only and usually limited to the victim's in-browser or in-app session data, not device takeover, tenant takeover, or domain-wide privilege gain.
• Downgrade for threat signal weakness: no KEV listing, no verified public campaigns, and EPSS 0.00032 all point to low near-term exploitation pressure.
• Keep above IGNORE: cross-origin leaks can still expose authenticated business data or session-adjacent secrets if your Android users access SSO-backed SaaS or internal apps through WebView.

Why not higher?

There is no code execution, no sandbox escape, and no evidence of active exploitation. More importantly, requiring Android client interaction means this cannot be mass-exploited the way perimeter or zero-click browser bugs can.

Why not lower?

This is still a real browser isolation failure, not a theoretical lint finding. If a managed Android user opens malicious content while authenticated to sensitive web apps, the attacker may get meaningful confidential data, so writing it off completely would be sloppy.

1. Force-update Chrome and Android System WebView — Use MDM or enterprise Play policy to push 149.0.7827.53 or later across managed Android devices. For a LOW verdict there is no SLA; treat this as backlog hygiene and complete it in the next routine mobile update wave.
2. Restrict untrusted content in embedded WebViews — Where you control Android apps, stop opening arbitrary external URLs inside privileged WebViews and prefer hardened browser flows or Custom Tabs for identity-sensitive journeys. With LOW, fold this into normal app-hardening work rather than emergency change.
3. Monitor Android version drift in MDM — Build a compliance view for com.android.chrome and com.google.android.webview versions so stragglers are visible. For LOW, handle drift during normal compliance cleanup and exception review.
4. Harden session abuse detection — Use IdP and SaaS telemetry to flag token replay, unusual mobile-origin sessions, and post-click account anomalies. This does not remove the bug, but it shortens time-to-detect if leaked data is actually monetized.

Run this on an auditor workstation with adb installed against a connected Android device or emulator with USB debugging enabled: bash check_webview_cve_2026_11097.sh <serial>. It needs no root, but it does need permission to query package metadata over adb shell.

#!/usr/bin/env bash
# check_webview_cve_2026_11097.sh
# Checks Chrome/WebView package versions on an Android device for CVE-2026-11097
# Usage: bash check_webview_cve_2026_11097.sh <device-serial>
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

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

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

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

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

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

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

WEBVIEW_PKG="com.google.android.webview"
CHROME_PKG="com.android.chrome"

WEBVIEW_VER=$(get_ver "$WEBVIEW_PKG")
CHROME_VER=$(get_ver "$CHROME_PKG")

if [ -z "$WEBVIEW_VER" ] && [ -z "$CHROME_VER" ]; then
  echo "UNKNOWN - neither $WEBVIEW_PKG nor $CHROME_PKG version could be read"
  exit 2
fi

STATUS="PATCHED"
DETAILS=()

if [ -n "$WEBVIEW_VER" ]; then
  if ver_ge "$WEBVIEW_VER" "$FIXED"; then
    DETAILS+=("$WEBVIEW_PKG=$WEBVIEW_VER (patched)")
  else
    STATUS="VULNERABLE"
    DETAILS+=("$WEBVIEW_PKG=$WEBVIEW_VER (< $FIXED)")
  fi
else
  DETAILS+=("$WEBVIEW_PKG=not_present_or_not_reported")
fi

if [ -n "$CHROME_VER" ]; then
  if ver_ge "$CHROME_VER" "$FIXED"; then
    DETAILS+=("$CHROME_PKG=$CHROME_VER (patched)")
  else
    STATUS="VULNERABLE"
    DETAILS+=("$CHROME_PKG=$CHROME_VER (< $FIXED)")
  fi
else
  DETAILS+=("$CHROME_PKG=not_present_or_not_reported")
fi

if [ "$STATUS" = "VULNERABLE" ]; then
  echo "VULNERABLE - ${DETAILS[*]}"
  exit 1
fi

echo "PATCHED - ${DETAILS[*]}"
exit 0

Sources

1. Chrome Releases 2026 archive
2. Chrome for Android Update (May 28, 2026)
3. Early Stable Update for Desktop (May 29, 2026)
4. Android Developers: Build web apps in WebView
5. Google Play: Android System WebView
6. CISA Known Exploited Vulnerabilities Catalog
7. FIRST EPSS data and statistics
8. Vulnerability-Lookup Chrome June 2026 batch search