This looks less like a front-door smash and more like tricking someone into handing the keys through a half-open window
CVE-2026-11029 is an *improper input validation* issue in Chrome's Drag and Drop handling on Android, affecting versions prior to 149.0.7827.53. In plain terms, Chrome is accepting drag-and-drop input it should scrutinize harder, which creates an opportunity for a malicious web page to abuse that gesture path when a user interacts with attacker-controlled content.
Because there is no vendor CVSS or vendor severity, this needs a fresh assessment. The real-world risk lands at MEDIUM, not because browsers are unimportant, but because the attack chain is narrowed by three hard frictions: Android-only reach, likely required user interaction, and a client-side blast radius rather than unauthenticated server-side compromise. Low EPSS and no KEV/exploitation evidence keep this out of the emergency lane.
4 steps from start to impact.
Lure the victim into Chrome on Android
- Victim uses Google Chrome on Android
- Chrome version is below 149.0.7827.53
- Victim opens attacker-controlled content
- Android-only immediately cuts the reachable fleet versus cross-platform Chrome bugs
- Enterprise mobile fleets often have auto-update enabled through Play/EMM
- No public exploit kit or campaign is currently tied to this CVE
Force a drag-and-drop interaction
- The vulnerable drag-and-drop code path must be reachable on the device
- User interaction is likely required to initiate the drag/drop flow
- Mobile drag-and-drop is a niche behavior in many real deployments
- Many phones are single-app, tap-only workflows with little drag/drop usage
- Security awareness, MTD, and simple user confusion can break the chain
Abuse the validation gap in Drag and Drop
- Attacker can supply crafted drag-and-drop input/state
- The vulnerable logic accepts that input without proper validation
- No public technical write-up or PoC currently shows a reliable exploit chain
- Chrome sandboxing and origin checks still constrain many outcomes
- Improper-input-validation bugs are often more brittle than memory-corruption bugs
Land browser-context impact
- Victim session has access to useful data or privileged web actions
- The exploit achieves more than cosmetic/UI disruption
- Impact depends on victim context at the moment of interaction
- No evidence this bypasses the full browser sandbox or yields device code execution
- Per-user compromise scope is much smaller than server-side pre-auth bugs
149.0.7827.53 and surface noncompliant devices to the mobility team. For MEDIUM, run this through normal operations and finish full remediation within the 365-day window.- A perimeter vuln scan will not find this in any meaningful way because the bug lives in a client browser, not an exposed server service.
- A WAF does not help much; the vulnerable code is on the victim device, and the malicious content can be delivered from anywhere that looks like normal web traffic.
- Desktop-focused EDR alone is not the answer for Android fleets; if you do not have EMM/MTD telemetry, you are mostly blind on version state and mobile user interaction.
The supporting signals.
| In-the-wild status | No confirmed exploitation found in the sources reviewed, and the CVE is not in CISA KEV as of 2026-06-05. |
|---|---|
| Public PoC | No public PoC located. That does not make it safe, but it does reduce immediate copy-paste attacker pressure. |
| EPSS | 0.00047 (~0.047% probability over 30 days). That is *very low* and consistent with a niche, interaction-heavy client-side path. |
| KEV status | Not listed in the CISA KEV Catalog; no KEV-added date applies. |
| Affected versions | Google Chrome on Android versions before 149.0.7827.53. |
| Fixed version | Treat 149.0.7827.53 or later as the security target version for Android Chrome. Public Chrome release posts show the 149 branch rolling across Android and desktop in late May 2026. |
| CVSS-style interpretation | There is no authoritative CVSS vector yet. My *assessed analogue* is roughly CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N, which is squarely MEDIUM because user interaction is the decisive friction. |
| Exposure model | This is a client-side mobile browser issue, not an internet-facing daemon. Shodan/Censys/FOFA are largely irrelevant for direct exposure counting; inventory and EMM telemetry are what matter. |
| Disclosure timing | CVE disclosure is 2026-06-04 from the supplied intel. Related Chrome 149 release activity appeared on 2026-05-28 and 2026-05-29. |
| Reporter | Not publicly established in the reviewed sources. I did not find a Google advisory line naming an external researcher for this specific CVE. |
Sources.
- Chrome Releases: Chrome for Android Update (149.0.7827.48)
- Chrome Releases: Early Stable Update for Desktop (149.0.7827.53/.54)
- Chrome Releases 2026 archive
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS overview
- FIRST EPSS API documentation
- Quanteta CVE tracker entry referencing CVE-2026-11029
- VulDB CVE listing for CVE-2026-11029
Why this verdict
- ASSESSED AT MEDIUM because user interaction is the choke point: the attack appears to require a drag-and-drop flow, which is a much less dependable trigger than a pure drive-by page load.
- Android-only narrows the exposed population: this is not all Chrome users, and it is not an exposed enterprise service reachable at scale from the internet.
- No exploit pressure signals: EPSS is extremely low, there is no KEV entry, and I found no public PoC or campaign tying attackers to this bug right now.
Why not higher?
I am not taking this to HIGH because the public facts do not show server-side reach, unauthenticated code execution, sandbox escape, or active exploitation. The combination of Android-only scope and likely drag/drop interaction requirement compounds downward pressure in real fleets.
Why not lower?
I am not dropping this to LOW because Chrome on Android is still a widely deployed user platform, and browser bugs can become meaningful when chained with phishing or identity abuse. Even with heavy friction, improper validation in a browser input path deserves patching attention, not backlog oblivion.
Crowdsourced verification payload.
Run this on an auditor workstation with adb installed, or in CI against a fleet export of Chrome versions. Example: python3 check_chrome_android_cve_2026_11029.py --adb for a connected device, or python3 check_chrome_android_cve_2026_11029.py --version 149.0.7827.48. No root is required; ADB must be authorized on the device if you use --adb.
#!/usr/bin/env python3
# check_chrome_android_cve_2026_11029.py
# Exit codes:
# 0 = PATCHED
# 1 = VULNERABLE
# 2 = UNKNOWN / error
import argparse
import re
import subprocess
import sys
PATCHED = (149, 0, 7827, 53)
PKG = "com.android.chrome"
def parse_version(v):
m = re.match(r'^(\d+)\.(\d+)\.(\d+)\.(\d+)$', v.strip())
if not m:
return None
return tuple(int(x) for x in m.groups())
def cmp_version(a, b):
return (a > b) - (a < b)
def get_version_from_adb(serial=None):
cmd = ["adb"]
if serial:
cmd += ["-s", serial]
cmd += ["shell", "dumpsys", "package", PKG]
try:
out = subprocess.check_output(cmd, stderr=subprocess.STDOUT, text=True, timeout=20)
except Exception as e:
print(f"UNKNOWN: failed to run adb/dumpsys: {e}")
sys.exit(2)
for line in out.splitlines():
if "versionName=" in line:
ver = line.split("versionName=", 1)[1].strip()
return ver
return None
def main():
ap = argparse.ArgumentParser(description="Check Chrome on Android for CVE-2026-11029")
ap.add_argument("--version", help="Chrome version string, e.g. 149.0.7827.48")
ap.add_argument("--adb", action="store_true", help="Query a connected Android device via adb")
ap.add_argument("--serial", help="ADB device serial to target")
args = ap.parse_args()
version = None
if args.version:
version = args.version.strip()
elif args.adb:
version = get_version_from_adb(args.serial)
if not version:
print("UNKNOWN: could not determine Chrome version from adb output")
sys.exit(2)
else:
print("UNKNOWN: provide --version or --adb")
sys.exit(2)
parsed = parse_version(version)
if not parsed:
print(f"UNKNOWN: unrecognized version format: {version}")
sys.exit(2)
if cmp_version(parsed, PATCHED) >= 0:
print(f"PATCHED: Chrome {version} is >= 149.0.7827.53")
sys.exit(0)
else:
print(f"VULNERABLE: Chrome {version} is < 149.0.7827.53")
sys.exit(1)
if __name__ == "__main__":
main()