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

CVE-2026-11278 is a cross-origin data leak in Chrome Custom Tabs on Android affecting Chrome before 149.0.7827.53. Custom Tabs are the browser surfaces Android apps open inside their own UX, so the interesting part is not generic web browsing but app-launched browser sessions that share Chrome state. The stated impact is confidentiality only: a crafted HTML page can leak cross-origin data, with no integrity or availability impact described.

The vendor-style 6.5/MEDIUM baseline overstates enterprise urgency because the decisive prerequisite is hidden in the description: the attacker is local. In practice that means a malicious or already-compromised Android app has to get onto the handset first, then weaponize Custom Tabs to siphon data. That is post-initial-access on a mobile endpoint, not an unauthenticated internet attack path, and there is no KEV listing, no public PoC, and a near-floor EPSS.

Why this verdict

• Downward pressure: requires local attacker position — the CVE description itself says *local attacker*, which implies the attacker is already on the Android device or has planted a malicious app there.
• Downward pressure: Android + Custom Tabs only — this is not generic Chrome desktop exposure and not every mobile workflow uses reachable Custom Tabs paths.
• Downward pressure: confidentiality-only impact — there is no code execution, sandbox escape, or persistence; blast radius is typically one user session on one handset.
• Downward pressure: low threat telemetry — no KEV listing, no public PoC located, and user-supplied EPSS is effectively floor-level.
• Residual risk remains — Custom Tabs share real browser state, so a successful exploit can still expose meaningful cross-origin data on devices that already hold corporate sessions.

Why not higher?

If this were a true unauthenticated remote browser bug that any website could hit directly across the open internet, the vendor 6.5 would be defensible. But the local-attacker prerequisite and Android-app delivery requirement compound the friction; most enterprises would already view that as a sign of prior compromise or malicious app installation. That is why this does not belong in HIGH or even a strong MEDIUM bucket.

Why not lower?

It is not IGNORE because Chrome on Android is widely deployed and Custom Tabs often inherit valuable authenticated browser state. If you run managed Android fleets with SSO-heavy mobile apps, a malicious app already on-device could use this bug to turn a foothold into real data exposure. That is enough to keep it above pure paperwork.

1. Enforce managed app allowlisting — Make malicious app placement harder by restricting installs to Managed Google Play / approved catalogs and blocking unknown sources. For a LOW verdict there is no formal mitigation SLA; treat this as backlog hygiene and verify the policy is in place during the next mobile control review.
2. Disable sideloading where business permits — This CVE gets real only after a local foothold, so cutting off sideloading materially lowers exposure. On managed Android, enforce the restriction through EMM policy and confirm exceptions are documented; for LOW, handle in routine hardening rather than emergency change.
3. Keep Chrome auto-updates enforced — Use EMM compliance to require Chrome for Android 149.0.7827.53+ and auto-update from Play. Because this is LOW, fold it into the normal mobile app update cadence rather than a crash patch window.
4. Monitor for risky app behavior — Mobile threat defense, Play Protect telemetry, and app reputation controls can catch the more realistic precursor: a suspicious app invoking browser-like flows or exfiltrating data. Again, no mitigation SLA applies here; prioritize on fleets that store high-value tokens on Android devices.

Run this on an auditor workstation with adb installed, against a connected Android device or emulator with USB debugging/enterprise shell access enabled. Invoke it as ./check_cve_2026_11278.sh <serial> or ./check_cve_2026_11278.sh for the default device; it needs permission to use adb, but no root on the handset.

#!/usr/bin/env bash
# check_cve_2026_11278.sh
# Verify Chrome for Android version for CVE-2026-11278.
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN / error

set -euo pipefail

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

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

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

VERSION="$("${ADB[@]}" shell dumpsys package com.android.chrome 2>/dev/null | tr -d '\r' | awk -F= '/versionName=/{print $2; exit}')"

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

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

if verlte "$VERSION" "$TARGET_VERSION" && [[ "$VERSION" != "$TARGET_VERSION" ]]; then
  echo "VULNERABLE - Chrome version $VERSION is earlier than $TARGET_VERSION"
  exit 1
fi

if [[ "$VERSION" == "$TARGET_VERSION" ]] || ! verlte "$VERSION" "$TARGET_VERSION"; then
  echo "PATCHED - Chrome version $VERSION is $TARGET_VERSION or later"
  exit 0
fi

echo "UNKNOWN - unable to determine state"
exit 2

Sources

1. NVD entry for CVE-2026-11278
2. Chrome Releases: Stable Channel Update for Desktop (Chrome 149 security fixes)
3. Chrome for Developers: Overview of Android Custom Tabs
4. Android Open Source Project: Implement Android Custom Tabs for Captive Portal Login
5. CISA Known Exploited Vulnerabilities Catalog
6. FIRST EPSS overview
7. FIRST EPSS API documentation
8. Chrome Releases: Chrome for Android Update (Chrome 149 rollout context)