This is a side door in the lobby rules, not a hole in the vault
CVE-2026-11302 is an *insufficient policy enforcement* flaw in Chrome for iOS affecting versions before 149.0.7827.53. Google says a remote attacker can use a crafted HTML page to bypass *discretionary access control*, which strongly suggests an app-level or browser-policy control bypass rather than code execution, sandbox escape, or device compromise.
The vendor's MEDIUM 4.3 baseline is slightly generous for most enterprises. In the real world this only matters on iOS devices running Chrome, and the impact is most meaningful where you actually rely on Chrome browser management / policy enforcement on iOS; that sharply narrows the exposed population, and the stated impact remains integrity-low with user interaction required.
3 steps from start to impact.
Land a user on vulnerable Chrome for iOS
- Target device is iPhone or iPad with Chrome for iOS installed
- Installed Chrome version is older than 149.0.7827.53
- User opens the malicious link in Chrome for iOS
- Many iOS users stay in Safari or managed in-app browsers instead of Chrome
- Mobile app auto-update and App Store rollout reduce long-lived exposure
- Email/web filtering and mobile threat defense can block known bad URLs before launch
Trigger the policy-enforcement gap
- The vulnerable code path is reachable from normal web content
- The relevant access-control or enterprise policy check is active in that browsing context
- If the affected control is only relevant in managed Chrome configurations, most consumer-style installs are unaffected in practice
- Modern URL filtering, isolation, or safe-browsing layers may stop the page before the bypass logic runs
Abuse the bypassed control
- The bypassed control protects a workflow the attacker can immediately benefit from
- The user remains in session long enough for follow-on abuse
- No evidence of persistence, sandbox escape, or OS-level compromise
- Blast radius appears limited to the browser app and possibly the managed profile context
The supporting signals.
| In-the-wild status | No active exploitation evidence found. Not present in CISA KEV as of 2026-06-05. |
|---|---|
| Public PoC | None found publicly in vendor references or common exploit-tracking sources at time of review. |
| EPSS | 0.0002 — effectively floor-level exploit probability; this matches the weak attacker economics of a niche client-side logic flaw. |
| KEV status | Not KEV-listed; no due date pressure from exploitation evidence. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N — remote and click-driven, but with only low integrity impact and no confidentiality or availability impact. |
| Affected versions | Chrome for iOS before 149.0.7827.53. |
| Fixed version | 149.0.7827.53 or later. Because this is an App Store-delivered mobile app, remediation is an app update, not an OS patch. |
| Exposure reality | Not internet-enumerable. Shodan/Censys-style exposure data is basically irrelevant here because this is a client-side iOS app, not a listening service. |
| Platform nuance | On iOS, browser apps generally must use WebKit under Apple's App Review rules, which tends to cap exploit blast radius compared with desktop Chrome-style engine compromise. |
| Disclosure / attribution | Disclosed 2026-06-05. Public reporting credit was not clearly attributed in the accessible references. |
noisgate verdict.
The decisive factor is population friction: this only matters on iOS devices using Chrome, and the business impact is most relevant where you're actually enforcing Chrome policies on iOS. That turns a vendor-medium web bug into a narrow managed-mobile control bypass with limited blast radius and no exploitation evidence.
Why this verdict
- Downward pressure: requires the right client population — vendor 4.3 assumes generic reachability, but this bug only lands on Chrome for iOS users, and many enterprises still default iOS browsing to Safari or managed app webviews.
- Downward pressure: likely only high-value where Chrome policy management is in play — Google documents Chrome browser management for Android and iOS, which implies the bypass matters most in organizations actually using those controls. That is a narrower exposed fraction than 'all Chrome users.'
- Downward pressure: app-scoped integrity impact only — the supplied vector is I:L with C:N/A:N. No code execution, no sandbox escape, and no evidence of cross-app or OS compromise means the blast radius stays small.
Why not higher?
There is no sign of active exploitation, KEV listing, public weaponization, or high-impact follow-on like RCE. Just as important, this is a user-interaction-dependent client-side iOS bug whose value drops sharply outside managed Chrome-on-iOS deployments.
Why not lower?
It is still a real security control bypass, not mere cosmetic weirdness. If your organization depends on Chrome for iOS policy enforcement for managed users, the bug can undercut an intentional access-control boundary, which is enough to keep it above IGNORE.
What to do — in priority order.
- Force App Store updates — Push Chrome for iOS 149.0.7827.53+ through MDM or your managed app workflow and verify completion in inventory. For a LOW verdict there is no emergency SLA, so treat this as backlog hygiene and complete it in the next normal mobile app maintenance cycle.
- Prefer managed browser policy paths only where needed — If only a subset of users truly needs Chrome-managed browsing on iOS, keep that population tight. Reducing the number of users relying on this policy path shrinks exposure while the app update propagates; again, for LOW this is hygiene work rather than a timed emergency action.
- Monitor mobile app inventory drift — Create a saved report for Chrome for iOS versions below 149.0.7827.53 and track stragglers by owner and business unit. This is the practical control here because network discovery will not find a client-side iOS browser flaw.
- Block obviously suspicious mobile destinations — Keep mobile web filtering, email-link scanning, and safe-browsing controls enabled to reduce the chance that users ever reach a crafted landing page. This does not fix the bug, but it meaningfully cuts the exploit opportunity set while you clean up version lag.
- Traditional external vulnerability scanning doesn't help; there is no exposed server-side fingerprint to probe.
- EDR on laptops is irrelevant for unmanaged iPhones and iPads; this is a mobile app-version problem.
- Network segmentation is mostly beside the point because exploitation is through normal outbound web browsing, not inbound access to a service.
Crowdsourced verification payload.
Run this on an auditor workstation or CI job against a CSV export from your MDM / UEM inventory that includes app name and version columns. Invoke it as python3 check_cve_2026_11302.py devices.csv or python3 check_cve_2026_11302.py devices.csv --app "Google Chrome"; no admin rights are needed.
#!/usr/bin/env python3
"""
check_cve_2026_11302.py
Purpose:
Assess MDM/UEM inventory for CVE-2026-11302 exposure in Chrome for iOS.
Usage:
python3 check_cve_2026_11302.py inventory.csv
python3 check_cve_2026_11302.py inventory.csv --app "Google Chrome"
Expected CSV:
Any CSV with columns resembling device name, app name, and app version.
Common examples:
DeviceName,AppName,AppVersion
device,application,version
Name,ManagedApp,ShortVersion
Exit codes:
0 = PATCHED (no vulnerable rows found, and no critical parsing ambiguity)
1 = VULNERABLE (one or more vulnerable rows found)
2 = UNKNOWN (could not confidently assess)
"""
import argparse
import csv
import re
import sys
from typing import Optional, Tuple
FIXED_VERSION = (149, 0, 7827, 53)
DEFAULT_APP_MATCH = "chrome"
def norm(s: str) -> str:
return re.sub(r'[^a-z0-9]+', '', (s or '').strip().lower())
def parse_version(v: str) -> Optional[Tuple[int, ...]]:
if not v:
return None
m = re.findall(r'\d+', v)
if not m:
return None
try:
return tuple(int(x) for x in m)
except ValueError:
return None
def cmp_version(a: Tuple[int, ...], b: Tuple[int, ...]) -> int:
max_len = max(len(a), len(b))
a2 = a + (0,) * (max_len - len(a))
b2 = b + (0,) * (max_len - len(b))
if a2 < b2:
return -1
if a2 > b2:
return 1
return 0
def pick_column(fieldnames, candidates):
if not fieldnames:
return None
normalized = {norm(f): f for f in fieldnames}
for c in candidates:
if norm(c) in normalized:
return normalized[norm(c)]
for f in fieldnames:
nf = norm(f)
for c in candidates:
if norm(c) in nf or nf in norm(c):
return f
return None
def main():
ap = argparse.ArgumentParser()
ap.add_argument('csv_file', help='Path to MDM/UEM inventory CSV')
ap.add_argument('--app', default='Google Chrome', help='App name to match (default: Google Chrome)')
args = ap.parse_args()
try:
with open(args.csv_file, 'r', encoding='utf-8-sig', newline='') as fh:
reader = csv.DictReader(fh)
fieldnames = reader.fieldnames
if not fieldnames:
print('UNKNOWN - CSV has no header row')
sys.exit(2)
device_col = pick_column(fieldnames, ['DeviceName', 'Device', 'Name', 'Hostname', 'SerialNumber', 'UDID'])
app_col = pick_column(fieldnames, ['AppName', 'Application', 'ManagedApp', 'App', 'Name'])
ver_col = pick_column(fieldnames, ['AppVersion', 'Version', 'ShortVersion', 'ApplicationVersion'])
os_col = pick_column(fieldnames, ['OS', 'Platform', 'OperatingSystem'])
if not app_col or not ver_col:
print(f'UNKNOWN - unable to find app/version columns in headers: {fieldnames}')
sys.exit(2)
wanted = norm(args.app)
vulnerable = []
unknown = []
assessed = 0
for idx, row in enumerate(reader, start=2):
app_name = (row.get(app_col) or '').strip()
app_norm = norm(app_name)
if wanted not in app_norm and DEFAULT_APP_MATCH not in app_norm:
continue
# Optional platform sanity check if present
if os_col:
os_val = (row.get(os_col) or '').lower()
if os_val and 'ios' not in os_val and 'ipad' not in os_val:
continue
assessed += 1
device_name = (row.get(device_col) or f'row:{idx}').strip()
ver_raw = (row.get(ver_col) or '').strip()
ver = parse_version(ver_raw)
if ver is None:
unknown.append((device_name, app_name, ver_raw, 'unparseable version'))
continue
if cmp_version(ver, FIXED_VERSION) < 0:
vulnerable.append((device_name, app_name, ver_raw))
if assessed == 0:
print('UNKNOWN - no matching Chrome for iOS rows found in CSV')
sys.exit(2)
if vulnerable:
print('VULNERABLE')
print(f'Found {len(vulnerable)} vulnerable installation(s) of Chrome for iOS < 149.0.7827.53:')
for dev, app, ver in vulnerable:
print(f' - {dev}: {app} {ver}')
if unknown:
print(f'Also found {len(unknown)} matching row(s) with unknown version parsing.')
sys.exit(1)
if unknown:
print('UNKNOWN')
print('No confirmed vulnerable installs found, but some matching rows could not be parsed:')
for dev, app, ver, reason in unknown:
print(f' - {dev}: {app} {ver!r} ({reason})')
sys.exit(2)
print('PATCHED')
print('All matching Chrome for iOS rows are at or above 149.0.7827.53')
sys.exit(0)
except FileNotFoundError:
print(f'UNKNOWN - file not found: {args.csv_file}')
sys.exit(2)
except Exception as e:
print(f'UNKNOWN - unexpected error: {e}')
sys.exit(2)
if __name__ == '__main__':
main()
If you remember one thing.
Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.