Insufficient validation of untrusted input in Tab Group Sync in Google Chrome on Android prior to 149

CVE-2026-11034 is an *improper input validation* bug in Tab Group Sync for Google Chrome on Android. Per the supplied intel, affected versions are Chrome on Android before 149.0.7827.53; in public rollout terms, Google shipped Chrome 149.0.7827.59 for Android on June 2, 2026, and stated Android carries the same security fixes as the corresponding desktop stable release. Because the bug lives in a feature-specific sync path, reachability is narrower than a generic browser parsing bug: the victim has to be on Android Chrome, unpatched, and hit the affected tab-group/sync workflow.

The vendor's MEDIUM 6.1 rating is basically fair, but the *enterprise* story is slightly less urgent than that score implies. The biggest downward pressure is the attack chain's practical friction: user interaction is required, the flaw is Android-only, the vulnerable path is Tab Group Sync rather than core renderer code, and the stated impact is only low confidentiality/integrity with no availability loss. Based on the supplied CVSS vector, this looks like a bounded browser-profile or sync-state issue, *not* device compromise, sandbox escape, or a fleet-wide wormable condition.

Why this verdict

• User interaction drags it down: UI:R means this is not a zero-click browser compromise; the attacker needs a real person to browse attacker-controlled content and hit the affected workflow.
• Feature-specific reach is narrower than CVSS implies: the bug sits in Tab Group Sync on Android, which implies Chrome sync usage and the relevant tab-group path, not just 'any Chrome page load on any platform.'
• Impact is bounded: the supplied vector advertises only low confidentiality and integrity impact with no availability loss, which is a long way from handset takeover or enterprise identity compromise.
• No exploitation signal: no KEV listing, no public PoC found, and the supplied EPSS is extremely low, so there is no evidence-based reason to inflate this above routine patch operations.
• But not lower than MEDIUM: Chrome on Android is deployed at enormous scale, often preinstalled, and browser bugs remain an initial-access surface; if you have a large managed mobile fleet, you still want version compliance.

Why not higher?

This does not look like modern mobile kill-chain material. There is no published evidence here of code execution, sandbox escape, account takeover, or active exploitation, and the attack path compounds multiple friction points: Android-only, UI-required, and feature-specific.

Why not lower?

Calling it LOW would underweight the fact that Chrome is one of the most widely deployed mobile applications in enterprise-adjacent environments, including BYOD. Even limited-impact browser bugs deserve a place in the patch queue when the population is this broad and the fix is already shipping.

1. Force Chrome auto-update through EMM — Push Managed Google Play or equivalent enterprise mobility policy so Chrome updates are not left to user discretion. For a MEDIUM noisgate verdict there is no mitigation SLA; use this as standard hygiene while you work the actual app update through the 365-day remediation window.
2. Restrict Chrome sync in managed work profiles — If your Android program allows Chrome in work contexts, limit or disable sync where it is not business-necessary. That directly removes the feature path most relevant to this bug; again, no mitigation SLA applies here, so do it as policy hardening rather than an emergency block.
3. Inventory vulnerable Android Chrome builds — Query your MDM/EMM for devices with Chrome below the fixed floor and build a cleanup list. This is the control that matters operationally because exploit detection is weak; with a MEDIUM verdict, there is no mitigation SLA — go straight to the 365-day remediation window.
4. Separate personal and work browsing where possible — Use managed browser policies or work-profile separation so consumer sync features are less likely to intersect with enterprise data handling. This reduces blast radius if a user does encounter malicious content before patching.

Run this from an auditor workstation with Android Debug Bridge (adb) installed, pointed at a USB-connected or remotely managed Android device. Invoke it as ./check_chrome_android.sh for a single attached device or ./check_chrome_android.sh <serial> for a specific handset; no root is required, but adb access or managed debugging access is.

#!/usr/bin/env bash
# check_chrome_android.sh
# Check whether Chrome on Android is vulnerable to CVE-2026-11034
# Uses adb to read com.android.chrome versionName.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN / error

set -u

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

fail_unknown() {
  echo "UNKNOWN: $1"
  exit 2
}

if ! command -v "$ADB_BIN" >/dev/null 2>&1; then
  fail_unknown "adb not found in PATH"
fi

ADB_CMD=("$ADB_BIN")
if [ -n "$SERIAL_ARG" ]; then
  ADB_CMD+=("-s" "$SERIAL_ARG")
fi

# Ensure device is reachable
if ! "${ADB_CMD[@]}" get-state >/dev/null 2>&1; then
  fail_unknown "no reachable adb device"
fi

# Read versionName from package manager / dumpsys
VERSION=$("${ADB_CMD[@]}" shell dumpsys package "$PKG" 2>/dev/null | tr -d '\r' | sed -n 's/.*versionName=\([^ ]*\).*/\1/p' | head -n1)

if [ -z "$VERSION" ]; then
  VERSION=$("${ADB_CMD[@]}" shell cmd package list packages -f "$PKG" 2>/dev/null | tr -d '\r' | head -n1)
fi

if [ -z "$VERSION" ]; then
  fail_unknown "could not determine Chrome version for $PKG"
fi

# Compare dotted numeric versions.
vercmp() {
  # returns: 0 equal, 1 greater, 2 less
  local a="$1" b="$2"
  local IFS='.'
  local i
  read -r -a va <<< "$a"
  read -r -a vb <<< "$b"
  local len=${#va[@]}
  if [ ${#vb[@]} -gt $len ]; then
    len=${#vb[@]}
  fi
  for ((i=0; i<len; i++)); do
    local na=${va[i]:-0}
    local nb=${vb[i]:-0}
    if ((10#$na > 10#$nb)); then
      return 1
    elif ((10#$na < 10#$nb)); then
      return 2
    fi
  done
  return 0
}

vercmp "$VERSION" "$THRESHOLD"
CMP=$?

case "$CMP" in
  0|1)
    echo "PATCHED: Chrome version $VERSION is >= $THRESHOLD"
    exit 0
    ;;
  2)
    echo "VULNERABLE: Chrome version $VERSION is < $THRESHOLD"
    exit 1
    ;;
  *)
    fail_unknown "unexpected version comparison result"
    ;;
esac

Sources

1. Chrome stable desktop advisory for 149.0.7827.53/54 and CVE listing
2. Chrome Releases 2026 archive showing Android stable 149.0.7827.59 and same security fixes note
3. Chrome for Android early stable 149.0.7827.48 rollout
4. Chrome for Testing current stable version availability
5. CISA Known Exploited Vulnerabilities Catalog
6. FIRST EPSS model documentation
7. Google Chrome Help: Update Google Chrome on Android
8. Google Chrome Help: Sign in and sync in Chrome