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

CVE-2026-11247 is an insufficient policy enforcement flaw in Custom Tabs in Google Chrome on Android that can let a remote attacker leak cross-origin data using a crafted HTML page. The affected population is narrower than plain "Chrome users": the victim has to be on Chrome for Android before the fixed train and hit the malicious content through a flow that actually uses Custom Tabs. In practice, the Android stable release carrying the fix is Chrome 149.0.7827.59, while Google ties the security fix set to the corresponding desktop 149.0.7827.53/54 release.

Google's LOW / 3.1 label is basically fair, and if anything a little generous for enterprise patch triage. The real-world chain needs a victim click, a vulnerable Android device, a Custom Tabs execution path, and conditions that make a cross-origin leak actually useful; the payoff is limited to confidentiality leakage, not code execution, persistence, or broad tenant compromise.

Why this verdict

• Downward adjustment: requires user interaction — a remote attacker still has to get the victim onto attacker-controlled HTML, so this is not wormable or opportunistic internet spray at server scale.
• Downward adjustment: Android + Custom Tabs only — the prerequisite implies a narrower exposure pool than ordinary Chrome browsing. Enterprises with small managed Android fleets or low Custom Tabs dependence have materially less risk than the vendor baseline suggests.
• Downward adjustment: low blast radius — successful exploitation leaks some cross-origin data in the victim's browser context, but it does not buy code execution, persistence, admin rights, or broad tenant compromise.
• Slight upward adjustment: browser-session context can still matter — if the victim is authenticated to SSO, internal portals, or sensitive SaaS, even a low-confidence data leak can expose useful crumbs. That keeps this above IGNORE.

Why not higher?

There is no evidence of active exploitation, no public PoC, and no sign this bug is broadly reliable or easy to weaponize. More importantly, the chain compounds friction: attacker-controlled content, user interaction, Android-only targeting, and a Custom Tabs-specific execution path all suppress reachable population.

Why not lower?

This is still a remote, no-auth client-side bug that can touch browser trust boundaries. For organizations with heavy Android BYOD or mobile-first SaaS usage, the per-user impact can still include sensitive session-adjacent leakage, so writing it off entirely would be too casual.

1. Force Chrome auto-update on Android — Use Play managed configurations or your MDM to ensure Chrome for Android reaches 149.0.7827.59+. Because the reassessed verdict is LOW, there is no SLA (treat as backlog hygiene), but you should still push it in the next normal mobile browser maintenance cycle.
2. Prefer managed browser flows for sensitive apps — Where your mobile stack allows it, route IdP, HR, finance, and internal portal links into your managed enterprise browser instead of arbitrary app-driven Custom Tabs. This reduces dependence on the affected execution path while backlog remediation catches up; for a LOW issue, do this as backlog hygiene rather than as emergency work.
3. Review internal app use of Custom Tabs — If you build Android apps, inventory where Custom Tabs are used for authenticated or sensitive workflows and decide whether those flows should stay there. For a LOW verdict there is no hard mitigation SLA, but this is the right engineering follow-up before the next release train.

Run this on an auditor workstation with Android platform-tools (adb) installed, not on the phone itself. Invoke it as ./check_cve_2026_11247.sh <device-serial> or ./check_cve_2026_11247.sh for the only connected device; it needs USB debugging or enterprise adb access, but no root.

#!/usr/bin/env bash
# check_cve_2026_11247.sh
# Detect whether a connected Android device has Chrome for Android below the
# fixed version associated with CVE-2026-11247.
#
# Operational fixed version on Android stable: 149.0.7827.59
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN / error

set -u

FIXED_VERSION="149.0.7827.59"
PACKAGE="com.android.chrome"
SERIAL="${1:-}"

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

version_lt() {
  # returns 0 (true) if $1 < $2
  local a="$1" b="$2"
  if [[ "$a" == "$b" ]]; then
    return 1
  fi
  local first
  first=$(printf '%s\n%s\n' "$a" "$b" | sort -V | head -n1)
  [[ "$first" == "$a" ]]
}

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 accessible Android device via adb"
  exit 2
fi

DUMPSYS_OUT=$(adb_cmd shell dumpsys package "$PACKAGE" 2>/dev/null)
if [[ -z "$DUMPSYS_OUT" ]]; then
  echo "UNKNOWN: unable to query package $PACKAGE"
  exit 2
fi

VERSION=$(printf '%s
' "$DUMPSYS_OUT" | sed -n 's/.*versionName=//p' | head -n1 | tr -d '\r')
if [[ -z "$VERSION" ]]; then
  VERSION=$(adb_cmd shell cmd package dump "$PACKAGE" 2>/dev/null | sed -n 's/.*versionName=//p' | head -n1 | tr -d '\r')
fi

if [[ -z "$VERSION" ]]; then
  echo "UNKNOWN: Chrome package found but versionName could not be determined"
  exit 2
fi

if version_lt "$VERSION" "$FIXED_VERSION"; then
  echo "VULNERABLE: $PACKAGE version $VERSION is below fixed version $FIXED_VERSION"
  exit 1
else
  echo "PATCHED: $PACKAGE version $VERSION is at or above fixed version $FIXED_VERSION"
  exit 0
fi

Sources

1. Google Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
2. Google Chrome Releases - Chrome for Android Update (June 2, 2026)
3. Chromium issue 497865734
4. CISA Known Exploited Vulnerabilities Catalog
5. FIRST EPSS overview
6. FIRST EPSS data and stats
7. CVE-2026-11247 summary mirror with vendor references