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

CVE-2026-10984 is a UI spoofing flaw in Accessibility in Google Chrome on Android. Affected builds are Chrome on Android prior to 149.0.7827.53; Google shipped the Android stable fix as 149.0.7827.59 on 2026-06-02, and the CVE record describes the issue as allowing a remote attacker to perform UI spoofing via a crafted HTML page.

Google's internal Chromium label says High, but the CISA ADP CVSS 5.4 / Medium is closer to operational reality. The attacker needs a user on Android Chrome to land on a malicious page, and the demonstrated impact is misleading UI, not code execution, sandbox escape, or silent data theft. That makes it useful for credential theft and step-up phishing, but not a reason to drop everything across a 10,000-host estate unless your mobile fleet heavily relies on unmanaged Android browsing.

Why this verdict

• Downward pressure: attacker position is just remote web content, but it still requires a user click on Android Chrome. This is not wormable, not reachable like a server bug, and not silently triggerable across the fleet.
• Downward pressure: Android-only scope narrows exposed population. If your estate is mostly desktop Chrome, this is a minority slice, not a whole-fleet emergency.
• Downward pressure: impact is deceptive UI, not code execution. The practical outcome is phishing enablement or action spoofing, which matters, but usually at a per-user account level.
• Upward pressure: Chrome is massively deployed and mobile users trust browser prompts. On devices where users approve payments, SSO, or step-up auth from Chrome, UI spoofing can materially increase phishing conversion.

Why not higher?

There is no evidence here of remote code execution, sandbox escape, data exfiltration by itself, or privileged compromise of the handset. The exploit chain also depends on user interaction and a phishing-style delivery step, which is exactly the kind of compounding friction that should keep this out of HIGH.

Why not lower?

This is still a remote browser bug in a ubiquitous app, and UI spoofing on mobile can directly support credential theft, consent phishing, or fraudulent approvals. If your workforce uses Android Chrome for identity flows, banking portals, or admin consoles, the business risk is more than cosmetic.

1. Force Chrome updates through managed Play — Use managed Google Play or your EMM/UEM to push the fixed Android Chrome build and verify rollout. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but in practice this is an easy app-update hygiene win and should be folded into normal mobile patching.
2. Restrict risky mobile browsing paths — Where feasible, keep admin portals, privileged SSO flows, and sensitive finance workflows off unmanaged mobile browsing. This reduces the value of UI spoofing even before every device is updated; implement as policy during the normal remediation window.
3. Lean on phishing-resistant auth — Prefer passkeys/FIDO2 and origin-bound authentication for accounts that users access from mobile. These controls blunt spoofed login experiences because wrong-origin pages fail to obtain the same authentication outcome; maintain continuously, not just for this CVE.
4. Monitor mobile-origin identity anomalies — Hunt for suspicious Android-origin sign-ins, anomalous consent grants, and impossible-travel events tied to mobile sessions. This is the best detective control because the browser bug itself will rarely leave a distinct endpoint artifact.

Run this from an auditor workstation with Android Debug Bridge (adb) installed and a USB-connected or network-connected Android device that has debugging access enabled, or adapt the same package query for your EMM remote shell. Invoke it as ./check_chrome_android_cve_2026_10984.sh <serial> or ./check_chrome_android_cve_2026_10984.sh for the only attached device. No root is required, but you do need permission to run adb shell against the target device.

#!/usr/bin/env bash
# check_chrome_android_cve_2026_10984.sh
# Determine whether Google Chrome on Android is vulnerable to CVE-2026-10984.
# Affected: Chrome on Android < 149.0.7827.53
# Fixed:    Chrome on Android >= 149.0.7827.53 (stable rollout noted as 149.0.7827.59)
#
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN / error

set -u

PKG="com.android.chrome"
FIXED="149.0.7827.53"
SERIAL="${1:-}"
ADB=(adb)

if [[ -n "$SERIAL" ]]; then
  ADB+=( -s "$SERIAL" )
fi

command -v adb >/dev/null 2>&1 || {
  echo "UNKNOWN - adb not found in PATH"
  exit 2
}

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

# Pull versionName from package metadata
VERSION=$("${ADB[@]}" shell dumpsys package "$PKG" 2>/dev/null | tr -d '\r' | awk -F= '/versionName=/{print $2; exit}')

if [[ -z "$VERSION" ]]; then
  # Fallback path using pm dump
  VERSION=$("${ADB[@]}" shell pm dump "$PKG" 2>/dev/null | tr -d '\r' | awk -F= '/versionName=/{print $2; exit}')
fi

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

ver_ge() {
  # returns 0 if $1 >= $2
  [[ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | tail -n1)" == "$1" ]]
}

if ver_ge "$VERSION" "$FIXED"; then
  echo "PATCHED - $PKG version $VERSION >= $FIXED"
  exit 0
else
  echo "VULNERABLE - $PKG version $VERSION < $FIXED"
  exit 1
fi

Sources

1. Official CVE JSON record for CVE-2026-10984
2. Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
3. Chrome Releases - Chrome for Android Update (June 2, 2026)
4. Chromium issue 514022635
5. FIRST EPSS data and statistics
6. CISA Known Exploited Vulnerabilities Catalog
7. Google Chrome Help - Update Google Chrome on Android
8. Android Enterprise Help - Manage app updates