← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-11205 · CWE-20 · Disclosed 2026-06-04

Insufficient validation of untrusted input in Chrome for iOS in Google Chrome on iOS prior to 149

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

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

"Real bug, but it needs a very coached victim flow on a non-server iOS browser path."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Stage a malicious QR lure

The attacker needs a crafted QR payload that drives the victim into the vulnerable Chrome-for-iOS code path. There is no public exploit kit or named weaponized tool tied to this CVE; assume a custom phishing page, poster, email attachment, or chat image delivering the QR content.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Traditional vuln scanners will not see this well. Detection is mostly indirect through MDM app inventory, phishing telemetry, and user-reporting.
STEP 02

Walk the victim through specific gestures

The CVE description explicitly says exploitation requires the user to engage in specific UI gestures, which is much narrower than "visit a page". That means the exploit chain depends on the victim completing a precise interaction sequence in Chrome on iOS.
Conditions required:
  • Victim performs the exact gesture sequence needed by the bug
  • Chrome for iOS remains the browser handling the flow
Where this breaks in practice:
  • 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
Detection/coverage: Browser telemetry on iOS is limited. You are more likely to see the lure in mail or messaging telemetry than a high-fidelity exploit signal on-device.
STEP 03

Trigger UXSS in the browser context

If the vulnerable flow is reached, the attacker can inject arbitrary script or HTML in a browser context, creating a universal cross-site scripting style outcome. Practically, that can enable phishing overlays, DOM manipulation, or theft of data available to the affected page/session.
Conditions required:
  • Victim reaches the vulnerable QR/UI path
  • Target page or session of interest is accessible in Chrome on iOS
Where this breaks in practice:
  • 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
Detection/coverage: WAFs and network IDS generally do not have visibility into a client-side browser state confusion like this. Detection falls back to IdP anomaly logs, suspicious session use, and user-reported browser weirdness.
STEP 04

Monetize the session

The best-case attacker outcome is usually account or data abuse against whatever SaaS or internal web app the victim is already using in Chrome on iOS. Think session riding, content spoofing, credential harvesting, or access to data visible in the page context.
Conditions required:
  • Victim is authenticated to something valuable in Chrome on iOS
  • The attacker has a follow-on collection or phishing objective
Where this breaks in practice:
  • 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
Detection/coverage: Look for impossible-travel, fresh device-cookie issuance, abnormal mobile browser sessions, and suspicious OAuth re-prompts. Vulnerability scanners will mostly just tell you version exposure.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence of active exploitation found in the reviewed sources, and not listed in CISA KEV.
Proof-of-concept availabilityNo public PoC repo or exploit write-up identified. The public record currently looks limited to the CVE/CNA text and mirrored advisories.
EPSS0.00033 from the supplied intel, which is extremely low in absolute terms and consistent with a low-likelihood, user-driven exploit path.
KEV statusNot KEV-listed per the CISA Known Exploited Vulnerabilities Catalog.
CVSS vectorCVSS: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 versionsChrome for iOS prior to 149.0.7827.53.
Fixed version149.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 realityShodan/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 date2026-06-04.
Reporter / creditNo public finder credit is visible in the reviewed advisory material. The Chromium issue is referenced but appears permission-restricted.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (4.3/10)

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.

HIGH Version exposure and fixed build
MEDIUM Severity downgrade based on user-interaction friction and client-side scope
LOW Exact exploit chain details because the Chromium issue is restricted and no public PoC is available

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.

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
What doesn't work
  • 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.
06 · Verification

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.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/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())\n
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, do not treat this like a drop-everything browser zero-day. Pull an MDM report for Chrome on iOS, identify anything below 149.0.7827.53, and fold the upgrade into your next normal mobile app update cycle; for a LOW verdict there is no noisgate mitigation SLA and no noisgate remediation SLA beyond backlog hygiene, so the right move is routine cleanup, user comms about untrusted QR codes, and exception review only for high-risk mobile users who access sensitive SaaS through Chrome on iPhone.

Sources

  1. Chrome Releases: Chrome Stable for iOS Update (149.0.7827.45)
  2. Chrome Releases: Early Stable Update for Desktop (149.0.7827.53/.54)
  3. Chrome vendor-referenced advisory URL for 149 train security fixes
  4. CISA Known Exploited Vulnerabilities Catalog
  5. FIRST EPSS overview
  6. FIRST EPSS data and stats
  7. Vulnerability-Lookup entry for CVE-2026-11205
  8. Chromium issue reference for CVE-2026-11205
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.