This is a fake floor tile, not a blown front door
CVE-2026-11205 is a UXSS issue in Chrome for iOS where insufficient input validation in a QR-driven flow can let a remote attacker inject arbitrary script or HTML after persuading the victim to perform specific UI gestures. The affected range is Google Chrome on iOS before 149.0.7827.53; the fixed build is 149.0.7827.53.
paragraphs
4 steps from start to impact.
Stage a malicious QR lure
- Victim runs Chrome for iOS older than 149.0.7827.53
- Victim can be reached with a QR code lure
- Victim uses Chrome, not another browser, for the scan/open flow
- This is not a blind internet attack against a listening service
- The attacker must control both delivery and user behavior around the QR code
- Enterprise users often do not scan random QR codes in managed workflows
Walk the victim through specific gestures
- Victim performs the exact gesture sequence needed by the bug
- Chrome for iOS remains the browser handling the flow
- Extra interaction is a major reliability killer in real campaigns
- Default-browser settings, QR apps, and iOS handoff behavior can break the chain
- User hesitation or minor flow changes can collapse exploitation
Trigger UXSS in the browser context
- Victim reaches the vulnerable QR/UI path
- Target page or session of interest is accessible in Chrome on iOS
- Impact stays at the browser/session layer; this is not native iOS code execution
- MFA, token binding, and short-lived sessions reduce downstream payoff
- Same-device, same-browser scope limits blast radius
Monetize the session
- Victim is authenticated to something valuable in Chrome on iOS
- The attacker has a follow-on collection or phishing objective
- No evidence here of wormability, mass unauthenticated compromise, or device takeover
- Each hit is user-by-user and session-by-session
- Enterprise value depends heavily on mobile web app usage patterns
The supporting signals.
| In-the-wild status | No public evidence of active exploitation found in the reviewed sources, and not listed in CISA KEV. |
|---|---|
| Proof-of-concept availability | No public PoC repo or exploit write-up identified. The public record currently looks limited to the CVE/CNA text and mirrored advisories. |
| EPSS | 0.00033 from the supplied intel, which is extremely low in absolute terms and consistent with a low-likelihood, user-driven exploit path. |
| KEV status | Not KEV-listed per the CISA Known Exploited Vulnerabilities Catalog. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N — network-reachable in theory, but user interaction is mandatory and the impact is low confidentiality/integrity loss with no availability hit. |
| Affected versions | Chrome for iOS prior to 149.0.7827.53. |
| Fixed version | 149.0.7827.53. Public Chrome-for-iOS release notes show 149.0.7827.45 was released on 2026-05-27, so the vulnerable window is narrow around that 149 train. |
| Scanning and exposure reality | Shodan/Censys/FOFA-style exposure counts are effectively not applicable here because this is a client-side iOS app issue, not an internet-facing daemon. Your real exposure metric is managed iPhone fleet version inventory via MDM. |
| Disclosure date | 2026-06-04. |
| Reporter / credit | No public finder credit is visible in the reviewed advisory material. The Chromium issue is referenced but appears permission-restricted. |
noisgate verdict.
The decisive factor is the interaction burden: this is not just "click a link," it requires a victim to follow a specific QR-driven UI sequence inside Chrome on iOS. That sharply narrows both reachable population and exploit reliability, so the vendor's MEDIUM score overstates the operational urgency for most enterprise fleets.
Why this verdict
- Downward pressure: requires specific UI gestures beyond ordinary browsing, which is a real-world exploit reliability tax.
- Downward pressure: client-side iOS browser only; this is not an internet-facing service you can mass-scan and mass-hit.
- Downward pressure: no KEV, no public exploitation, and very low EPSS reduce priority versus browser RCEs or actively abused bugs.
- Residual risk remains: UXSS can still steal or spoof session data for users already authenticated to valuable SaaS or internal apps in mobile Chrome.
Why not higher?
There is no sign of native code execution, sandbox escape, wormability, or unauthenticated one-click mass exploitation. The need for a QR lure plus specific user gestures turns this into a narrow, socially engineered client attack rather than a fleet-burning browser emergency.
Why not lower?
It is still a real security boundary failure in a popular browser context, and UXSS can meaningfully impact SSO sessions, webmail, and internal portals on affected iPhones. If you have executives or high-risk users who routinely use Chrome on iOS for business SaaS, the bug is not ignorable just because exploitation is awkward.
What to do — in priority order.
- Force mobile browser app updates — Use MDM or enterprise app compliance policy to push Chrome for iOS to 149.0.7827.53 or later and flag stragglers. For a LOW verdict there is no formal noisgate mitigation SLA; treat this as backlog hygiene and clear it in the next standard mobile app maintenance cycle.
- Reduce QR-code trust — Warn users that unsolicited QR codes in email, chat, posters, and documents should be treated like links from strangers. This directly attacks the first exploit step and is the most realistic temporary control while normal update rollout catches up.
- Harden session value — Enforce phishing-resistant MFA, short session lifetimes, and conditional access on SaaS and internal web apps used from mobile browsers. That does not stop the UXSS itself, but it lowers the payoff if a mobile web session is targeted.
- Use MDM compliance gates — If high-risk groups rely on Chrome on iOS, make minimum app version a compliance condition before access to sensitive apps. For LOW, there is no SLA clock, but this is worth doing for executives, admins, and privileged mobile users.
- A perimeter WAF does not solve a client-side QR/UI-triggered browser bug; the vulnerable state is on the device.
- A network vulnerability scanner will not meaningfully validate exploitability here because there is no listening service to probe.
- Desktop EDR assumptions do not translate cleanly to iOS managed apps; on-device visibility and response options are much thinner.
Crowdsourced verification payload.
Run this on an auditor workstation or CI runner, not on the iPhone itself. Export your MDM/app inventory to CSV with columns like device_id,app_name,version, then run python3 check_chrome_ios_cve_2026_11205.py mdm_inventory.csv; no admin rights are required.
#!/usr/bin/env python3\n# check_chrome_ios_cve_2026_11205.py\n#\n# Purpose:\n# Check an MDM/exported inventory CSV for vulnerable Chrome for iOS versions\n# related to CVE-2026-11205.\n#\n# Expected CSV columns (case-insensitive, best effort):\n# device_id, app_name, version\n#\n# Exit codes:\n# 0 = all matching Chrome for iOS entries are PATCHED\n# 1 = one or more matching entries are VULNERABLE\n# 2 = UNKNOWN (missing/invalid data or no matching rows found)\n\nimport csv\nimport re\nimport sys\nfrom typing import List, Optional, Tuple\n\nFIXED_VERSION = (149, 0, 7827, 53)\n\ndef norm(s: str) -> str:\n return (s or "").strip().lower()\n\ndef parse_version(v: str) -> Optional[Tuple[int, ...]]:\n if not v:\n return None\n parts = re.findall(r"\d+", v)\n if len(parts) < 4:\n return None\n try:\n return tuple(int(x) for x in parts[:4])\n except ValueError:\n return None\n\ndef cmp_version(a: Tuple[int, ...], b: Tuple[int, ...]) -> int:\n max_len = max(len(a), len(b))\n aa = a + (0,) * (max_len - len(a))\n bb = b + (0,) * (max_len - len(b))\n return (aa > bb) - (aa < bb)\n\ndef looks_like_chrome_ios(app_name: str) -> bool:\n name = norm(app_name)\n # Best-effort matching for common inventory labels\n needles = [\n "chrome",\n "google chrome",\n "chrome for ios",\n "com.google.chrome.ios",\n "google llc chrome"\n ]\n return any(n in name for n in needles)\n\ndef main() -> int:\n if len(sys.argv) != 2:\n print("UNKNOWN - usage: python3 check_chrome_ios_cve_2026_11205.py <inventory.csv>")\n return 2\n\n path = sys.argv[1]\n try:\n with open(path, newline="", encoding="utf-8-sig") as f:\n reader = csv.DictReader(f)\n if not reader.fieldnames:\n print("UNKNOWN - CSV has no header row")\n return 2\n\n fieldmap = {norm(h): h for h in reader.fieldnames}\n\n app_field = None\n version_field = None\n device_field = None\n\n for candidate in ["app_name", "app", "application", "name", "product"]:\n if candidate in fieldmap:\n app_field = fieldmap[candidate]\n break\n\n for candidate in ["version", "app_version", "application_version"]:\n if candidate in fieldmap:\n version_field = fieldmap[candidate]\n break\n\n for candidate in ["device_id", "device", "hostname", "serial", "udid"]:\n if candidate in fieldmap:\n device_field = fieldmap[candidate]\n break\n\n if not app_field or not version_field:\n print("UNKNOWN - required columns not found; need app_name/app and version")\n return 2\n\n rows_seen = 0\n matched = 0\n vulnerable = []\n unknown = []\n patched = []\n\n for row in reader:\n rows_seen += 1\n app_name = row.get(app_field, "")\n version_raw = row.get(version_field, "")\n device_id = row.get(device_field, "") if device_field else f"row-{rows_seen}"\n\n if not looks_like_chrome_ios(app_name):\n continue\n\n matched += 1\n ver = parse_version(version_raw)\n if ver is None:\n unknown.append((device_id, app_name, version_raw))\n continue\n\n if cmp_version(ver, FIXED_VERSION) < 0:\n vulnerable.append((device_id, app_name, version_raw))\n else:\n patched.append((device_id, app_name, version_raw))\n\n except FileNotFoundError:\n print(f"UNKNOWN - file not found: {path}")\n return 2\n except Exception as e:\n print(f"UNKNOWN - failed to read CSV: {e}")\n return 2\n\n if matched == 0:\n print("UNKNOWN - no Chrome for iOS rows matched in the provided inventory")\n return 2\n\n for device_id, app_name, version_raw in vulnerable:\n print(f"VULNERABLE - device={device_id} app={app_name} version={version_raw}")\n\n for device_id, app_name, version_raw in patched:\n print(f"PATCHED - device={device_id} app={app_name} version={version_raw}")\n\n for device_id, app_name, version_raw in unknown:\n print(f"UNKNOWN - device={device_id} app={app_name} version={version_raw}")\n\n if vulnerable:\n return 1\n if unknown:\n return 2\n return 0\n\nif __name__ == "__main__":\n sys.exit(main())\nIf you remember one thing.
Sources
- Chrome Releases: Chrome Stable for iOS Update (149.0.7827.45)
- Chrome Releases: Early Stable Update for Desktop (149.0.7827.53/.54)
- Chrome vendor-referenced advisory URL for 149 train security fixes
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS overview
- FIRST EPSS data and stats
- Vulnerability-Lookup entry for CVE-2026-11205
- Chromium issue reference for CVE-2026-11205
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.