01 · The Real Story
This is a fake badge on a real uniform: convincing enough to fool users, not enough to break the building
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.
"This is mobile phishing ammo, not a fleet-burning RCE."
02 · The Attack Path
3 steps from start to impact.
STEP 01
Get the target onto a malicious page
The attacker uses a standard phishing kit / smishing lure to drive an Android Chrome user to attacker-controlled HTML. No prior auth is required, but the victim must browse to the page in vulnerable Chrome on Android. In enterprise terms, this is still an initial-access content delivery problem, not direct infrastructure reachability.
Conditions required:
- Victim uses Chrome on Android below 149.0.7827.53
- Victim clicks or opens attacker-controlled content
- Chrome is the active browser used for the session
Where this breaks in practice:
- Requires user interaction
- Android-only scope cuts out Windows/macOS/Linux Chrome fleets
- Safe Browsing, SMS filtering, mail filtering, and user suspicion reduce reach
Detection/coverage: VM and patch scanners can identify app version; content-level detection is harder because the exploit begins as a normal web page rather than a binary payload.
STEP 02
Render deceptive browser UI
Using the Accessibility bug, the malicious page manipulates presentation so the victim sees spoofed browser or security-adjacent UI. The practical weapon here is a phishing landing page with UI mimicry, not an exploit chain that yields native code execution. The attacker wins if the victim trusts the spoofed prompt, origin indicator, or workflow enough to continue.
Conditions required:
- The vulnerable Accessibility path is triggered by crafted HTML
- Victim remains in-session long enough to interact with the spoofed UI
Where this breaks in practice:
- This is still bounded by what the browser can visually misrepresent
- Users may notice origin mismatch, password-manager behavior, or inconsistent page flow
- Enterprise browsers with managed Safe Browsing and anti-phishing controls still catch many campaigns before this matters
Detection/coverage: There is no reliable network signature for 'UI spoofing succeeded'; visibility comes from phishing telemetry, browser protections, and downstream identity detections such as impossible travel or suspicious sign-ins.
STEP 03
Harvest credentials or trigger a fraudulent action
The endgame is usually credential capture, consent phishing, or transaction deception. The weaponized tool at this stage is the attacker backend collecting passwords, MFA prompts, or submitted form data. Impact is real, but it is social-engineering-amplified browser abuse, not host takeover.
Conditions required:
- Victim submits data or approves a spoofed action
- Target workflow is something users routinely trust on mobile
Where this breaks in practice:
- MFA, FIDO2/passkeys, conditional access, and app-to-browser separation reduce value
- Password managers often refuse to autofill on wrong origins, exposing the scam
- Blast radius is usually per-user account, not full-device compromise
Detection/coverage: Identity telemetry is your best net: risky sign-ins, anomalous OAuth grants, impossible travel, token reuse, and mobile phishing reports.
03 · Compensating Control
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.
What doesn't work
- A network vulnerability scanner does not meaningfully reduce risk here; this is a client-side browser flaw, not a listening service.
- Perimeter firewalls/WAFs are mostly irrelevant because the exploit rides normal outbound browsing to attacker-controlled web content.
- EDR on desktops does nothing for unmanaged Android devices; if your mobile estate is the exposure, desktop telemetry won't save you.
04 · Intelligence Metadata
The supporting signals.
| In-the-wild status | No public active exploitation evidence found in the sources reviewed, and not listed in CISA KEV. |
|---|---|
| PoC availability | No public PoC or GitHub exploit repo located in primary-source review; the Chromium issue exists but its details are not publicly exposed without access. |
| EPSS | 0.00035 — effectively background noise, consistent with a low-likelihood exploitation outlook. |
| KEV status | Not listed in the CISA Known Exploited Vulnerabilities Catalog as of 2026-06-05. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L — remote and easy to trigger, but user interaction is required and impact is limited. |
| Affected versions | Google Chrome on Android < 149.0.7827.53 per the CVE record. |
| Fixed version | Android stable update shipped as Chrome 149.0.7827.59 on 2026-06-02; desktop counterpart security fixes are referenced from 149.0.7827.53/54. |
| Exposure reality | There is no internet-exposed server census angle here — this is a client-side mobile browser issue. Population is large in consumer terms, but enterprise exposure depends on how many managed Android users actually browse sensitive workflows in Chrome. |
| Disclosure | CVE published 2026-06-04; Chrome Android stable update noted 2026-06-02. |
| Reporter | Reported by Google in the Chrome stable release notes; Chromium issue ID 514022635. |
Sources.
- Official CVE JSON record for CVE-2026-10984
- Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
- Chrome Releases - Chrome for Android Update (June 2, 2026)
- Chromium issue 514022635
- FIRST EPSS data and statistics
- CISA Known Exploited Vulnerabilities Catalog
- Google Chrome Help - Update Google Chrome on Android
- Android Enterprise Help - Manage app updates
05 · The Call
Final Verdict
= UNCHANGED to MEDIUM (5.2/10)
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.
06 · Verification
Crowdsourced verification payload.
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