Inappropriate implementation in Custom Tabs in Google Chrome on Android prior to 149

CVE-2026-11035 is an *inappropriate implementation* flaw in Chrome for Android's Custom Tabs path. Affected builds are Chrome on Android before 149.0.7827.53; the user-supplied advisory text says a local attacker with low privileges and user interaction can turn that flaw into a privilege escalation condition. In plain English: the attacker already needs code execution as an app on the device, then has to drive the victim through a Custom Tabs flow to get more capability than the Android/browser boundary should allow.

Google's HIGH 7.3 score is fair if you score the bug in a lab, where the end-state impact is severe. In the field, it is overstated for enterprise patch triage because every major prerequisite narrows reality: Android-only, local attacker, attacker app already present, user interaction required, and a Custom Tabs-specific execution path. That turns this into a *post-initial-access mobile abuse primitive*, not a remotely reachable mass-compromise event.

Why this verdict

• Down from 7.3 because attacker must already be on the device: AV:L/PR:L means this is not a remote entry point; it assumes the adversary has already landed a malicious app or equivalent local code execution.
• Further down because it needs user interaction: UI:R means exploitation is not silent and fully automatable at internet scale.
• Further down because the reachable population is narrower than Chrome overall: this is Chrome on Android and specifically a Custom Tabs path, not every desktop browser session or every generic web render path.
• EPSS is near zero and there is no KEV signal: the available exploitation telemetry does not support urgent reprioritization upward.
• Blast radius is per-device: even when successful, the likely impact is bounded to the already-compromised handset and user context, not a one-shot fleet event.

Why not higher?

This is not unauthenticated remote exploitation from the internet, and it does not give an attacker their first foothold. Every gate in the chain compounds downward pressure: local app presence, Android-only scope, vulnerable Custom Tabs path, and required user interaction. That is not CRITICAL or HIGH patch-train material for most enterprise queues.

Why not lower?

I am not pushing this to LOW because Chrome on Android is common, the impacted component sits on a sensitive app-to-browser trust boundary, and the declared CIA impact is all high once exploitation lands. On mobile fleets with broader app-install freedom, a browser-mediated privilege jump still matters enough to keep out of backlog-hygiene territory.

1. Restrict unapproved app installs — Use EMM/MDM policy, Play Protect enforcement, and enterprise app allowlisting to reduce the core prerequisite: a malicious local app. For a MEDIUM noisgate verdict there is no mitigation SLA — go straight to the 365-day remediation window, but this control is worth maintaining continuously because it removes the attacker's hardest dependency.
2. Inventory Chrome for Android versions — Confirm which managed Android devices are below 149.0.7827.53 and whether Chrome is the active browser/Custom Tabs provider. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but version visibility prevents this from becoming a blind spot on mobile fleets.
3. Monitor suspicious app-to-browser launches — Use mobile threat defense, app telemetry, or EDR-style mobile controls to look for unusual Custom Tabs invocation patterns from low-trust apps. For MEDIUM, there is no mitigation SLA — go straight to the 365-day remediation window; this is a detection-and-containment control, not a substitute for updating.
4. Enforce conditional access for browser-backed enterprise apps — If exploitation aims to steal or misuse browser-mediated sessions, conditional access, device posture checks, and step-up auth can reduce the value of the gained privilege. For MEDIUM, there is no mitigation SLA — go straight to the 365-day remediation window, but apply this broadly because it cushions many mobile browser abuse paths.

Run this from an auditor workstation with adb installed, against a connected Android device or emulator that has USB debugging or network debugging enabled. Invoke it as ./check_chrome_android_cve_2026_11035.sh or ./check_chrome_android_cve_2026_11035.sh emulator-5554; no root is required, but adb shell dumpsys package com.android.chrome must be permitted.

#!/usr/bin/env bash
# check_chrome_android_cve_2026_11035.sh
# Purpose: Determine whether Chrome on Android is vulnerable to CVE-2026-11035
# Logic: Chrome versions prior to 149.0.7827.53 are VULNERABLE
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN / could not determine

set -u

TARGET_VERSION="149.0.7827.53"
PKG="com.android.chrome"
ADB_BIN="${ADB_BIN:-adb}"
SERIAL="${1:-}"

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

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

get_version() {
  adb_cmd shell dumpsys package "$PKG" 2>/dev/null | sed -n 's/.*versionName=\([^[:space:]]*\).*/\1/p' | head -n1
}

if ! command -v "$ADB_BIN" >/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

if ! adb_cmd shell pm path "$PKG" >/dev/null 2>&1; then
  echo "UNKNOWN: Chrome package $PKG not installed or inaccessible"
  exit 2
fi

VERSION=$(get_version)

if [ -z "$VERSION" ]; then
  echo "UNKNOWN: unable to read Chrome versionName"
  exit 2
fi

case "$VERSION" in
  *[!0-9.]* )
    echo "UNKNOWN: unexpected version format: $VERSION"
    exit 2
    ;;
esac

if version_lt "$VERSION" "$TARGET_VERSION"; then
  echo "VULNERABLE: Chrome version $VERSION is older than $TARGET_VERSION"
  exit 1
else
  echo "PATCHED: Chrome version $VERSION is $TARGET_VERSION or newer"
  exit 0
fi

Sources

1. Chrome Releases: Chrome for Android Update (Chrome 149 baseline rollout)
2. Chrome for Developers: Overview of Android Custom Tabs
3. Chromium source: Chrome Custom Tabs Security FAQ
4. Academic paper: Tabbed Out: Subverting the Android Custom Tab Security Model
5. GovCERT.HK advisory covering Chrome prior to 149.0.7827.53
6. Quanteta CVE Tracker listing CVE-2026-11035 publication metadata
7. CISA Known Exploited Vulnerabilities Catalog
8. VulDB entry for CVE-2026-11035