This is a bad hallway sign in a side entrance, not a master key to the building
CVE-2026-11204 is a navigation-restriction bypass in the Signin component of Google Chrome on iOS. A malicious site can use crafted HTML to steer or break intended navigation controls during a sign-in-related flow, affecting Chrome on iOS versions earlier than 149.0.7827.53.
The vendor's MEDIUM 6.5 is technically fair in a vacuum, but it overstates enterprise urgency. This is still a user-interaction, client-side, iOS-only browser UI/control-boundary flaw with no public exploitation evidence, no KEV listing, no server-side foothold, and no clear path to device compromise; in real patch queues, that is LOW backlog hygiene, not front-of-line work.
3 steps from start to impact.
Deliver a malicious page
- Victim uses Chrome on iOS, not another browser
- Installed app version is earlier than 149.0.7827.53
- Victim opens attacker-controlled content
- Requires a real user click path
- Population is limited to iOS Chrome users
- Managed mobile fleets often auto-update apps quickly
Trigger the Signin navigation bypass
Signin implementation to bypass intended navigation restrictions. Based on the advisory text, the effect is a policy/UI boundary failure rather than memory corruption or code execution.- Victim reaches the affected sign-in or related navigation path
- Attacker-controlled page can invoke the relevant browser behavior
- Bug details remain restricted in Chromium
- Exploit path appears tied to a specific browser component, not generic web content handling
- iOS Chrome is constrained by Apple's webview model
Abuse trust in the altered flow
- User trusts the resulting page or flow enough to continue
- The bypass meaningfully changes a sign-in journey or restricted destination
- No stated confidentiality or availability impact
- Blast radius is per-user and per-session
- Modern IdPs, phishing-resistant MFA, and managed-app controls can blunt downstream abuse
The supporting signals.
| In-the-wild status | No public evidence of active exploitation found in the reviewed sources, and it is not listed in CISA KEV. |
|---|---|
| PoC availability | No public PoC or weaponized GitHub repo found. The linked Chromium issue is still access-restricted, which usually slows copycat exploitation. |
| EPSS | 0.0002 from the user-supplied intel, which is effectively negligible near-term exploitation probability. Exact percentile was not independently verified from the public sources reviewed. |
| KEV status | Not KEV-listed as checked against the CISA Known Exploited Vulnerabilities Catalog after disclosure on 2026-06-04. |
| CVSS meaning | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N means remote reachability with no auth, but user interaction is mandatory and the modeled impact is integrity-only. |
| Affected versions | Chrome on iOS < 149.0.7827.53. Google had already shipped 149.0.7827.45 for iOS on 2026-05-27, so this is a narrow follow-on patch boundary. |
| Fixed version | 149.0.7827.53 or later. For enterprise, trust MDM-reported app version rather than user screenshots. |
| Exposure / scanning reality | Not meaningfully Shodan/Censys/FOFA-addressable. This is a client-side mobile app flaw, not an internet-facing service; exposure measurement is an MDM inventory problem, not an external attack-surface problem. |
| Disclosure / reporting | Published 2026-06-04 by Chrome; Google credits the bug internally as reported by Google on 2026-04-22 in the Chrome 149 advisory. |
| Platform containment | Google documents that Chrome on iOS uses Apple's WKWebView, which materially limits exploit primitives compared with full desktop Chrome. |
noisgate verdict.
The single biggest severity reducer is that this bug sits in Chrome on iOS sign-in/navigation UX, not an exposed server or a memory-corruption path to code execution. It needs a victim to use a specific mobile browser, open attacker content, and then meaningfully act inside the manipulated flow, which sharply narrows both reachable population and blast radius.
Why this verdict
- User interaction is mandatory, so this is not a wormable or passive drive-by enterprise event. Starting from vendor 6.5,
UI:Ris real friction and knocks priority down immediately. - Attacker position is only unauthenticated remote web content, but the required population is narrow. This only matters on iOS devices running Chrome, which is a much smaller and less privilege-rich target set than generic desktop Chrome.
- The impact is bounded to sign-in/navigation integrity inside a mobile browser context. There is no evidence here of code execution, sandbox escape, local privilege escalation, or durable device compromise.
Why not higher?
There is no active exploitation evidence, no KEV listing, no public PoC, and no indication of a memory-safety bug that attackers can readily chain into full compromise. The attack also depends on a specific client platform and a user completing a manipulated browsing/sign-in path.
Why not lower?
It is still a remote bug reachable from a malicious webpage with no authentication required on the attacker side. Because it touches the Signin path and navigation controls, it can still support phishing, redirect abuse, or trust-boundary bypass against individual users, so it does deserve patching.
What to do — in priority order.
- Force mobile app auto-update — Use Intune, Jamf, Workspace ONE, or your equivalent MDM to push/require Chrome on iOS 149.0.7827.53+ and flag older app versions. Because this is a LOW verdict, there is no SLA here beyond normal backlog hygiene; roll it into the next routine mobile application update cycle.
- Prefer hardened browsers for privileged mobile auth — For admin portals and high-risk SaaS sign-ins, steer users to your standard managed mobile browser policy and avoid stale Chrome-on-iOS clients. This is a sensible containment step while versions converge, but for a LOW finding it should be done as part of regular mobile control maintenance, not emergency change.
- Watch identity logs for weird mobile sign-in journeys — Monitor IdP telemetry for abnormal mobile OAuth redirects, suspicious consent flows, and unusual sign-in sequences from iPhone user-agents. This helps catch downstream abuse if the browser flaw is paired with phishing, and it can be deployed in the normal monitoring tuning cadence.
- A network IPS or edge firewall will not reliably help; the exploit medium is ordinary browser-delivered HTML in a client app.
- External attack-surface scanning will not prioritize this correctly because there is no internet-facing service banner to find.
- Desktop Chrome patch compliance dashboards are misleading here; this is specifically Chrome on iOS, so only MDM/mobile app inventory answers the question.
Crowdsourced verification payload.
Run this on an auditor workstation or CI job against an exported MDM CSV of installed iOS apps; do not run it on the iPhone itself. Invoke it as python3 check_chrome_ios_cve_2026_11204.py mdm_export.csv where the CSV has headers like device_name,platform,app_name,app_version; no admin rights are needed on the workstation.
#!/usr/bin/env python3
# check_chrome_ios_cve_2026_11204.py
# Exit codes:
# 0 = all matching Chrome on iOS entries are PATCHED
# 1 = one or more matching Chrome on iOS entries are VULNERABLE
# 2 = UNKNOWN / bad input / no matching inventory rows
import csv
import re
import sys
from pathlib import Path
FIXED_VERSION = "149.0.7827.53"
TARGET_NAMES = {
"google chrome",
"chrome",
"google chrome: fast & secure",
}
def normalize(s):
return (s or "").strip().lower()
def parse_version(v):
if not v:
return None
parts = re.findall(r"\d+", v)
if not parts:
return None
return tuple(int(x) for x in parts)
def cmp_versions(a, b):
la, lb = len(a), len(b)
n = max(la, lb)
a = a + (0,) * (n - la)
b = b + (0,) * (n - lb)
if a < b:
return -1
if a > b:
return 1
return 0
def is_ios(platform_value):
p = normalize(platform_value)
return p in {"ios", "iphone", "iphone os", "ipados", "ipad os"}
def is_chrome(app_name):
return normalize(app_name) in TARGET_NAMES
def main():
if len(sys.argv) != 2:
print("UNKNOWN - usage: python3 check_chrome_ios_cve_2026_11204.py <mdm_export.csv>")
sys.exit(2)
csv_path = Path(sys.argv[1])
if not csv_path.exists() or not csv_path.is_file():
print(f"UNKNOWN - file not found: {csv_path}")
sys.exit(2)
fixed = parse_version(FIXED_VERSION)
if fixed is None:
print("UNKNOWN - internal fixed version parse failure")
sys.exit(2)
required_headers = {"device_name", "platform", "app_name", "app_version"}
matches = []
unknowns = []
vulnerable = []
patched = []
try:
with csv_path.open("r", encoding="utf-8-sig", newline="") as fh:
reader = csv.DictReader(fh)
headers = set(reader.fieldnames or [])
if not required_headers.issubset(headers):
print("UNKNOWN - CSV must contain headers: device_name, platform, app_name, app_version")
sys.exit(2)
for row in reader:
device = (row.get("device_name") or "").strip() or "<unknown-device>"
platform = row.get("platform") or ""
app_name = row.get("app_name") or ""
app_version = (row.get("app_version") or "").strip()
if not is_ios(platform):
continue
if not is_chrome(app_name):
continue
matches.append(device)
parsed = parse_version(app_version)
if parsed is None:
unknowns.append((device, app_version or "<blank>"))
continue
if cmp_versions(parsed, fixed) < 0:
vulnerable.append((device, app_version))
else:
patched.append((device, app_version))
except Exception as e:
print(f"UNKNOWN - failed to read CSV: {e}")
sys.exit(2)
if not matches:
print("UNKNOWN - no Chrome on iOS rows found in inventory")
sys.exit(2)
for device, version in vulnerable:
print(f"VULNERABLE - {device} - Chrome iOS {version} < {FIXED_VERSION}")
for device, version in patched:
print(f"PATCHED - {device} - Chrome iOS {version} >= {FIXED_VERSION}")
for device, version in unknowns:
print(f"UNKNOWN - {device} - unparseable version: {version}")
if vulnerable:
sys.exit(1)
if unknowns:
sys.exit(2)
sys.exit(0)
if __name__ == "__main__":
main()
If you remember one thing.
Sources
- NVD entry for CVE-2026-11204
- Chrome 149 stable channel advisory listing CVE-2026-11204
- Chromium issue 505200733 referenced by the CVE
- Chrome stable for iOS 149.0.7827.45 release note
- Google Help note that Chrome on iOS uses WKWebView
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS API documentation
- CVE record mirror showing affected version metadata
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.