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

CVE-2026-11270 is a Chrome-for-Android UI implementation flaw that can leak cross-origin data from a crafted HTML page on versions prior to 149.0.7827.53, with public Android rollout evidence also showing the fixed stable train landing as 149.0.7827.59 on June 2-3, 2026. The bug is scoped to Android Chrome, requires the victim to load attacker-controlled web content, and the stated impact is data disclosure rather than code execution, sandbox escape, or account takeover by itself.

The vendor's MEDIUM 6.5 label is defensible in a lab because cross-origin data exposure in a browser is never nothing, but it overshoots the operational reality for enterprise patching. The biggest downward pressure is the combination of Android-only reach, user interaction/browser-session dependency, no active exploitation evidence, and no straightforward internet-exposed attack surface you can scan at scale.

Why this verdict

• Requires victim browsing in Chrome on Android: attacker position is unauthenticated remote, but only after convincing a user to open attacker-controlled content on the right browser and platform.
• Android-only scope cuts population hard: this is not desktop Chrome, not a server, and not a broadly scan-detectable edge service; many enterprises have a much smaller managed Android browser population than their Windows/macOS estates.
• Confidentiality-only impact: there is no evidence here of code execution, sandbox escape, persistence, or device takeover. A data leak primitive is materially less urgent than a browser memory-corruption chain.
• No KEV, no public PoC, tiny EPSS: exploitation evidence is weak across all three common prioritization signals.
• Modern controls interrupt the path early: Safe Browsing, secure email gateways, web filtering, MTD, conditional access, and short-lived SaaS tokens all add compounding friction after the user-click prerequisite.

Why not higher?

If this were a Chrome RCE, sandbox escape, or a same-bug-class issue with confirmed in-the-wild use, it would move up fast. But this CVE looks like a narrow disclosure bug on a mobile client, with multiple prerequisite steps and no exploitation evidence to cancel out that friction.

Why not lower?

It still sits above IGNORE because cross-origin data leakage in a browser can expose authenticated web content, and Chrome on Android is common enough in BYOD and managed mobile programs that some enterprise data is plausibly at risk. The vendor also rates the confidentiality impact as high within the vulnerable session, so this should be patched in routine hygiene rather than dismissed.

1. Enforce Chrome auto-update on Android — Use EMM/MDM managed Google Play policy to keep com.android.chrome on the current stable train. For a LOW verdict there is no mitigation SLA; treat this as backlog hygiene and push it in the next normal mobile app maintenance cycle.
2. Prefer managed app inventory over network scanners — Build a version report from Intune, Workspace ONE, MobileIron, or Google endpoint management rather than expecting vulnerability scanners to find this. For LOW, there is no mitigation SLA, so use the next reporting cycle to identify laggards and close them out.
3. Tighten mobile web access to sensitive apps — Where business-tolerable, require device trust or conditional access for sensitive SaaS sessions from mobile browsers. That reduces the value of any leaked browser-session data while you clean up vulnerable app versions in routine operations.
4. Monitor anomalous SaaS session reuse — Focus on IdP and SaaS telemetry for token replay, unusual mobile-origin access, and impossible-travel patterns. This will not detect the bug directly, but it is the most practical way to catch downstream abuse if a browser disclosure bug is exploited.

Run this from an auditor workstation that has adb installed and USB debugging or enterprise ADB access to the target Android device. Invoke it as ./check_cve_2026_11270.sh <device-serial> or ./check_cve_2026_11270.sh for the only attached device; no root is required, but the device must be reachable by adb and expose package metadata.

#!/usr/bin/env bash
# check_cve_2026_11270.sh
# Verify whether Google Chrome on an attached Android device is below the fixed version floor.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

PKG="com.android.chrome"
FIXED_VERSION="149.0.7827.53"
SERIAL="${1:-}"

adb_cmd() {
  if [ -n "$SERIAL" ]; then
    adb -s "$SERIAL" "$@"
  else
    adb "$@"
  fi
}

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

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

if ! adb_cmd get-state >/dev/null 2>&1; then
  echo "UNKNOWN: no reachable adb device"
  exit 2
fi

VERSION="$(adb_cmd shell dumpsys package "$PKG" 2>/dev/null | sed -n 's/.*versionName=//p' | head -n1 | tr -d '\r')"

if [ -z "$VERSION" ]; then
  VERSION="$(adb_cmd shell pm list packages -f "$PKG" 2>/dev/null | grep -q "$PKG" && adb_cmd shell dumpsys package "$PKG" 2>/dev/null | sed -n 's/.*versionName=//p' | head -n1 | tr -d '\r')"
fi

if [ -z "$VERSION" ]; then
  echo "UNKNOWN: Chrome package not found or version unreadable"
  exit 2
fi

case "$VERSION" in
  *[!0-9.]*|"")
    echo "UNKNOWN: unrecognized Chrome version '$VERSION'"
    exit 2
    ;;
esac

if version_ge "$VERSION" "$FIXED_VERSION"; then
  echo "PATCHED: Chrome version $VERSION >= $FIXED_VERSION"
  exit 0
else
  echo "VULNERABLE: Chrome version $VERSION < $FIXED_VERSION"
  exit 1
fi

Sources

1. Chrome 149 release notes
2. Chrome Releases blog homepage
3. Chrome Releases: Early Stable Update for Desktop (149.0.7827.53/.54)
4. CISA Known Exploited Vulnerabilities Catalog
5. FIRST EPSS project
6. CVE feed mirror showing CVE-2026-11270 description
7. Public Android stable rollout evidence for Chrome 149.0.7827.59