Race in Geolocation in Google Chrome on Android prior to 149

CVE-2026-11145 is a race condition in Chrome Geolocation on Android that affects versions before 149.0.7827.53. The published impact is cross-origin data leakage via a crafted HTML page, not code execution, persistence, or sandbox escape. In plain English: a malicious page may be able to win a timing bug around geolocation handling and read data it should not be able to read across origin boundaries.

The vendor's 6.5 / MEDIUM baseline is technically defensible, but it overstates patch urgency for enterprise fleet triage. This is Android-only, requires user interaction, has no KEV listing, no public exploitation evidence, no public PoC found, and the bug class itself implies the attacker still has to win a timing-sensitive race rather than hit a deterministic memory corruption primitive. That pushes it down from 'drop everything' to 'patch as normal browser hygiene.'

Why this verdict

• Android-only narrows reach: this is not a broad desktop Chrome fire; it only applies to Chrome on Android, which materially shrinks the exposed enterprise population.
• User interaction is mandatory: the attacker must get the victim to open crafted HTML, which implies phishing/adversary-controlled content delivery rather than unauthenticated internet exploitation.
• Race conditions are unreliable at scale: the bug class itself adds attacker friction because exploitation depends on timing and browser state, not just serving one malicious payload.
• Confidentiality-only impact caps severity: the published impact is cross-origin data leakage, not code execution, sandbox escape, persistence, or device compromise.
• Threat intel is cold: no KEV, no public exploitation evidence, no public PoC located, and EPSS is effectively near zero.

Why not higher?

This is not a browser RCE and not a sandbox escape. To get a higher bucket, I would want evidence of active exploitation, a public exploit chain, broader platform reach, or a cleaner deterministic primitive than a geolocation race with confidentiality-only impact.

Why not lower?

It still hits a widely deployed browser and can be triggered remotely through normal web content. Cross-origin leakage in a mainstream mobile browser is not meaningless backlog dust, especially where managed Android devices handle SSO, internal portals, or sensitive web apps.

1. Force Chrome auto-updates through managed Google Play — If you manage Android with Google endpoint management or EMM, make sure Chrome is approved and auto-updating so the vulnerable version ages out naturally. For a MEDIUM reassessment there is no mitigation SLA, so use this as normal hygiene while you work toward patch completion inside the 365-day remediation window.
2. Inventory Android Chrome versions now — Pull an MDM/EMM report for com.android.chrome and isolate devices below 149.0.7827.53; that gives you the real denominator instead of arguing from theoretical exposure. For MEDIUM, there is no mitigation SLA — go straight to remediation tracking and keep the straggler list moving toward the 365-day deadline.
3. Minimize Chrome geolocation permissions where business use does not require them — Where policy allows, revoke or discourage unnecessary location access for Chrome on managed Android devices to reduce the reachable vulnerable code path. This is a temporary exposure reduction, not a substitute for updating, and it can be rolled into normal mobile hardening work during the 365-day remediation window.
4. Prefer compliant managed devices for sensitive web access — Route high-value browser workflows—admin panels, finance, HR, privileged SaaS—onto managed devices that enforce app update compliance, instead of hoping unmanaged mobile browsers stay current. There is no mitigation SLA for this verdict, but this control reduces risk immediately while remediation proceeds.

Run this from an auditor workstation with adb installed against a managed Android device connected over USB or Wi-Fi. Example: ./check_chrome_android.sh ZY22XXXXXX; it needs adb device access only and does not require root.

#!/usr/bin/env bash
# check_chrome_android.sh
# Verify whether Google Chrome on Android is vulnerable to CVE-2026-11145
# Usage: ./check_chrome_android.sh [device-serial]
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN/usage, 3=adb/package error

set -u

PKG="com.android.chrome"
PATCHED_VERSION="149.0.7827.53"
ADB_BIN="adb"
SERIAL_ARG=""

if [[ $# -gt 1 ]]; then
  echo "UNKNOWN: Usage: $0 [device-serial]"
  exit 2
fi

if [[ $# -eq 1 ]]; then
  SERIAL_ARG="-s $1"
fi

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

# Ensure device is reachable
if ! $ADB_BIN $SERIAL_ARG get-state >/dev/null 2>&1; then
  echo "UNKNOWN: adb device not reachable"
  exit 3
fi

# Pull versionName from package manager
VERSION_RAW="$($ADB_BIN $SERIAL_ARG shell dumpsys package "$PKG" 2>/dev/null | tr -d '\r' | awk -F= '/versionName=/{print $2; exit}')"

if [[ -z "$VERSION_RAW" ]]; then
  echo "UNKNOWN: package $PKG not found or version unavailable"
  exit 3
fi

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

if version_ge "$VERSION_RAW" "$PATCHED_VERSION"; then
  echo "PATCHED: $PKG version $VERSION_RAW (patched floor: $PATCHED_VERSION)"
  exit 0
else
  echo "VULNERABLE: $PKG version $VERSION_RAW (patched floor: $PATCHED_VERSION)"
  exit 1
fi

Sources

1. CIRCL Vulnerability-Lookup record for CVE-2026-11145
2. Google Chrome stable channel update, June 2 2026
3. Chromium issue reference 501683745
4. CISA Known Exploited Vulnerabilities Catalog
5. FIRST EPSS overview
6. Google Chrome on Google Play
7. Google Help: Update Chrome on Android