Like finding a loose interior panel in one company car, not an unlocked gate to the whole fleet
CVE-2026-11202 is a client-side bug in Chrome for iOS that affects versions before 149.0.7827.53. A remote attacker would have to get a user onto a crafted HTML page, then leverage an inappropriate implementation flaw to potentially escape Chrome's internal sandbox boundary inside the iOS app context.
The vendor/NVD-style 8.8 HIGH score overstates enterprise urgency. In the real world this is user-driven, iOS-only, browser-client exploitation with no KEV entry, very low EPSS, no public exploit evidence found, and an Apple-controlled platform model where web-browsing apps must use WebKit and run inside iOS app protections; that sharply reduces exposed population and blast radius compared with a typical desktop-browser RCE.
4 steps from start to impact.
Deliver a malicious page
- Target uses Chrome on iOS
- Chrome version is earlier than 149.0.7827.53
- User opens attacker-controlled content
- Requires user interaction
- Many enterprises route links through secure email, mobile threat defense, or safe-browsing controls
- Not all iPhone users run Chrome; Safari-only populations are unaffected
Trigger the implementation flaw
- Reachable vulnerable code path from web content
- Exploit works against the victim device/build
- No public PoC found in GitHub or Exploit-DB searches as of 2026-06-06
- Bug details remain restricted in Chromium issue tracking
- Client-side reliability on mobile is usually worse than lab CVSS suggests
Escape Chrome's internal sandbox boundary
- Successful exploit primitive after page render
- Victim session contains useful browser state
- On iOS, browser apps are built on WebKit and remain inside Apple's app security model
- This is not the same as a straightforward path to full device takeover
Monetize app-level access
- Valuable authenticated sessions in Chrome for iOS
- Attacker can extract or act on stolen session state
- Impact is limited to users who browse sensitive apps from Chrome on iOS
- SSO protections, conditional access, and short-lived tokens reduce follow-on value
- Blast radius is per-user, not estate-wide
The supporting signals.
| In-the-wild status | No known active exploitation in the sources reviewed; not present in CISA KEV as of 2026-06-06. |
|---|---|
| Proof-of-concept availability | No public PoC located in quick checks across GitHub Advisory, GitHub code search results, and Exploit-DB; Chromium issue details are still restricted. |
| EPSS | 0.0009 (~0.09% 30-day probability), about the 25.57th percentile in the CIRCL/FIRST feed snapshot. |
| KEV status | Not KEV-listed; no CISA due date applies. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H — the big caveat is UI:R: the attacker still needs the user to open malicious content. |
| Affected versions | Chrome for iOS < 149.0.7827.53. The prior public stable iOS release found was 149.0.7827.45 on 2026-05-27, which makes the exposed window narrow in version terms. |
| Fixed version | 149.0.7827.53 or later for Chrome on iOS. No distro-backport angle here because this is an App Store mobile client. |
| Scanning / exposure data | Internet exposure telemetry from Shodan/Censys/FOFA is basically not meaningful here because this is a client-side iOS app, not an internet-facing server product. Use MDM inventory instead. |
| Disclosure date | Published 2026-06-04 in CVE/NVD records. |
| Reporter / source | CVE assigned by Chrome; the June 2, 2026 Chrome 149 release notes show many externally and internally reported issues, but this CVE's detailed bug remains restricted. |
noisgate verdict.
The decisive factor is reachability friction: this is a user-interaction-required, iOS-only client bug rather than an exposed enterprise service or a no-click browser zero-day with exploitation evidence. Even if exploitation works, the practical blast radius is usually one mobile browser session on one device, not broad host or server compromise.
Why this verdict
- UI-required client-side exploit path: starting from vendor 8.8, I subtract because the attacker needs the victim to open malicious web content; that is materially harder than unauthenticated server reachability.
- iOS-only and Chrome-only population: this is not all browsers and not all mobile devices. Requiring Chrome on iOS sharply narrows the exposed slice of a 10,000-host estate.
- Apple platform containment changes the math: iOS web-browsing apps must use WebKit and operate under iOS app security controls, so a Chrome-internal sandbox escape is still not equivalent to broad OS compromise.
- No exploitation signal: no KEV listing, no public campaign reporting, and a very low EPSS remove the urgency premium that would otherwise keep this in HIGH.
- Per-user blast radius: the realistic enterprise consequence is session theft or browser-context abuse for a subset of users, not mass lateral movement or wormability.
Why not higher?
There is no evidence here of active exploitation, no no-click path, and no exposure model comparable to a perimeter service. The combination of user interaction, mobile-only targeting, and client-app confinement prevents this from deserving a HIGH or CRITICAL response in most enterprises.
Why not lower?
This still starts from a remote attacker with no privileges required, and the bug class is described as a potential sandbox escape, which is not trivial. If a high-value user browses sensitive corporate apps from Chrome on iOS, successful exploitation could still expose sessions or data that matter.
What to do — in priority order.
- Inventory vulnerable app versions — Use MDM or EMM inventory to identify devices running Chrome for iOS < 149.0.7827.53. For a MEDIUM verdict there is no noisgate mitigation SLA — go straight to the 365-day remediation window, but you should still know your population before the next mobile app wave.
- Force or nudge the App Store update — Push Chrome for iOS 149.0.7827.53+ through your normal managed-mobile update process. There is no noisgate mitigation SLA here; complete the actual app remediation inside the 365-day remediation window, sooner for executive and admin device groups.
- Prefer managed browser controls — If you already use managed browsing, keep sensitive SaaS access pinned to a managed browser profile and monitor risky-link events. This does not replace patching, but it reduces the chance that a random phishing click turns into an exploitable page load while you work through the normal remediation window.
- Keep iOS current — Maintain current iOS/iPadOS baselines because Apple platform protections are part of the reason this scored down. This is supporting risk reduction, not a substitute for the Chrome update, and it can ride the same normal mobile maintenance cycle.
- Network vulnerability scanners won't help much; this is a client-side mobile app bug, not an internet-facing service fingerprint.
- WAF rules do nothing unless your own web apps are the delivery point; the malicious content can come from any external page.
- Assuming Safari patch status covers Chrome for iOS is sloppy; Chrome on iOS uses WebKit, but the vulnerable app package still has its own release and version boundary.
Crowdsourced verification payload.
Run this on an auditor workstation against an MDM-exported CSV that contains a Chrome-for-iOS version column. Example: python3 check_cve_2026_11202_ios_chrome.py devices.csv chrome_version or python3 check_cve_2026_11202_ios_chrome.py devices.csv AppVersion. No admin privileges are required.
#!/usr/bin/env python3\n# Check Chrome for iOS exposure to CVE-2026-11202 from an MDM CSV export\n# Usage: python3 check_cve_2026_11202_ios_chrome.py devices.csv chrome_version\n# Exit codes:\n# 0 = all rows PATCHED\n# 1 = at least one row VULNERABLE\n# 2 = UNKNOWN (missing/invalid data or mixed unknowns without vulnerable rows)\n\nimport csv\nimport re\nimport sys\nfrom pathlib import Path\n\nFIXED = (149, 0, 7827, 53)\n\ndef parse_version(s):\n if s is None:\n return None\n m = re.search(r'(\\d+)\\.(\\d+)\\.(\\d+)\\.(\\d+)', str(s))\n if not m:\n return None\n return tuple(int(x) for x in m.groups())\n\ndef status_for(version_text):\n v = parse_version(version_text)\n if v is None:\n return 'UNKNOWN'\n if v < FIXED:\n return 'VULNERABLE'\n return 'PATCHED'\n\ndef main():\n if len(sys.argv) != 3:\n print('UNKNOWN - usage: python3 check_cve_2026_11202_ios_chrome.py <csv_path> <version_column>')\n sys.exit(2)\n\n csv_path = Path(sys.argv[1])\n version_col = sys.argv[2]\n\n if not csv_path.exists():\n print(f'UNKNOWN - file not found: {csv_path}')\n sys.exit(2)\n\n vulnerable = 0\n patched = 0\n unknown = 0\n rows = 0\n\n with csv_path.open(newline='', encoding='utf-8-sig') as f:\n reader = csv.DictReader(f)\n if not reader.fieldnames or version_col not in reader.fieldnames:\n print(f'UNKNOWN - column not found: {version_col}')\n sys.exit(2)\n\n id_col = None\n for candidate in ('device_id', 'Device ID', 'serial', 'Serial Number', 'name', 'Device Name', 'hostname'):\n if candidate in reader.fieldnames:\n id_col = candidate\n break\n\n for row in reader:\n rows += 1\n device = row.get(id_col, f'row-{rows}') if id_col else f'row-{rows}'\n version_text = row.get(version_col, '')\n state = status_for(version_text)\n print(f'{device}: {state} (version={version_text})')\n if state == 'VULNERABLE':\n vulnerable += 1\n elif state == 'PATCHED':\n patched += 1\n else:\n unknown += 1\n\n if rows == 0:\n print('UNKNOWN - no data rows found')\n sys.exit(2)\n\n print(f'SUMMARY: VULNERABLE={vulnerable} PATCHED={patched} UNKNOWN={unknown}')\n\n if vulnerable > 0:\n print('VULNERABLE')\n sys.exit(1)\n if unknown > 0:\n print('UNKNOWN')\n sys.exit(2)\n\n print('PATCHED')\n sys.exit(0)\n\nif __name__ == '__main__':\n main()\nIf you remember one thing.
Sources
- Google Chrome Releases - Stable Channel Update for Desktop (Chrome 149 security fixes)
- Google Chrome Releases - Chrome Stable for iOS Update (149.0.7827.45 prior stable)
- GitHub Advisory Database - GHSA-2x2v-r3mf-2j25 / CVE-2026-11202
- Vulnerability-Lookup (CIRCL) - CVE-2026-11202 record with EPSS snapshot
- CISA Known Exploited Vulnerabilities Catalog
- Apple App Review Guidelines
- Apple Support - Intro to app security for iOS, iPadOS, and visionOS
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.