This is a peephole drilled into one user’s browser tab, not a master key to the building
CVE-2026-11298 is a same-origin policy bypass in Chrome for iOS that affects builds before 149.0.7827.53. In plain English: a malicious web page can abuse a Chrome-for-iOS implementation flaw to cross the browser’s origin boundary and interact with data that should stay isolated to another site, provided the victim is using vulnerable Chrome on iPhone or iPad and visits attacker-controlled content.
The vendor's MEDIUM 4.3 is slightly generous for enterprise patch triage. Same-origin bypasses are never harmless, but this one is still a client-side, user-driven, per-session attack with no RCE, no persistence, no server exposure, no KEV listing, and no public exploitation signal; that combination pushes it down into backlog-grade mobile browser risk unless you have a large managed iOS Chrome footprint handling sensitive SaaS sessions.
4 steps from start to impact.
Land the victim on attacker HTML
- Victim uses Google Chrome on iOS
- Installed version is prior to 149.0.7827.53
- Victim opens attacker-controlled or attacker-influenced content
- This is not a server-side bug; each exploitation attempt needs a live user session
- Many enterprises standardize on Safari or managed WebKit views on iOS, shrinking the exposed population
- App Store auto-update and MDM app update policy reduce dwell time once the fixed build is available
Break the browser origin boundary
- The vulnerable code path is reachable from web content
- Browser-side mitigations do not block the specific SOP bypass primitive
- Google has not published exploitation details, so attackers need their own bug research or a private PoC
- Chrome on iOS rides on Apple WebKit/WKWebView plumbing, which tends to limit how far a Chrome-specific logic bug can escape the app's browser context
Read or drive cross-origin web state
- Victim is simultaneously authenticated to a valuable target site in Chrome for iOS
- The target site's session is reachable from the compromised browser context
- Blast radius is mostly limited to the single user's browser sessions, not the device or enterprise fleet
- Cross-origin abuse is only valuable when the victim already holds live cookies or state for interesting internal or SaaS apps
- Per-app or IdP re-authentication, short-lived sessions, and conditional access reduce payoff
Exfiltrate session-bound data
- Attacker has a collection endpoint or action objective
- Enterprise data is accessible through the victim's browser session
- No direct path to code execution, device persistence, or lateral movement is described
- Impact is bounded by what the individual user can access from the mobile browser
The supporting signals.
| In-the-wild status | No public exploitation evidence found as of 2026-06-08; not KEV-listed. |
|---|---|
| PoC availability | No public PoC or weaponized exploit repo found in current public search results. Treat as *researcher/private-only* until proven otherwise. |
| EPSS | 0.0001 from the user-provided intel, which is effectively floor-level exploit probability. |
| KEV status | No. CISA KEV does not currently list this CVE. |
| CVSS vector meaning | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N = internet-deliverable, no auth needed, but user interaction is required and impact is limited to low integrity in the browser context. |
| Affected versions | Chrome for iOS prior to 149.0.7827.53. |
| Fixed version | 149.0.7827.53 or later. On iOS this lands through the App Store / MDM app update path, not OS package management. |
| Exposure reality | Shodan/Censys/FOFA are basically irrelevant here because this is a client-side mobile browser app, not an internet-exposed service. Reachability depends on users browsing hostile content, not on exposed TCP services. |
| Platform architecture | Chrome's own iOS web layer wraps WKWebView rather than shipping Blink in the standard path, which implies this bug is more likely a Chrome-for-iOS wrapper/logic flaw than a broad cross-platform Chrome engine break. |
| Disclosure metadata | Disclosed 2026-06-05. Public researcher credit was not found in the accessible advisories. |
noisgate verdict.
The decisive factor is population and position friction: this bug only matters when a user is on Chrome for iOS, on a specific unpatched app build, and then browses attacker content while holding valuable authenticated web sessions. That makes it a real but narrow post-click session abuse problem, not a broad enterprise compromise primitive.
Why this verdict
- Downward pressure: requires live user interaction — no victim, no bug; this is not passively reachable infrastructure risk.
- Downward pressure: Chrome-for-iOS-only population — many enterprises have a smaller managed iOS Chrome estate than Windows/macOS Chrome, and some mobile flows stay in Safari or managed WebViews.
- Downward pressure: session-bound blast radius — impact is limited to what the individual victim can access in their browser sessions, not fleet-wide code execution or device takeover.
- Downward pressure: no KEV / no public campaign / no public PoC found — there is no current signal that attackers are operationalizing this at scale.
- Upward pressure: same-origin bypasses are meaningful — if the victim has live sessions to sensitive SaaS or intranet apps in Chrome for iOS, cross-origin abuse can still leak or manipulate business data.
Why not higher?
To justify MEDIUM or HIGH here, you would want either broad exposed population, public exploitation, or materially higher impact such as RCE, sandbox escape, or account compromise at scale. We do not have that. This remains a user-driven browser-session issue with a narrow affected platform and no current threat intel amplifier.
Why not lower?
It is still a genuine SOP bypass, not cosmetic noise. If a high-value mobile user is logged into sensitive web apps, attacker-controlled HTML can potentially cross boundaries that should hold, so ignoring it entirely would understate the risk for mobile-heavy SaaS environments.
What to do — in priority order.
- Force-update Chrome on managed iOS — Use MDM/EMM app management to push 149.0.7827.53+ and confirm install state via app inventory. For a LOW verdict there is no noisgate mitigation SLA; treat this as backlog hygiene and complete in the normal remediation cycle.
- Reduce mobile browser session value — Shorten session lifetime for sensitive SaaS apps, require step-up auth for risky actions, and prefer app-based access where feasible. This lowers the payoff if a mobile browser session is abused before the patch is everywhere.
- Steer sensitive access away from Chrome on iOS until coverage is clean — If you have conditional-access or MAM controls, restrict especially sensitive admin portals from vulnerable Chrome-for-iOS builds. Use this selectively for privileged users or regulated apps rather than fleet-wide disruption.
- Watch SaaS audit logs for mobile-origin anomalies — Monitor for unusual actions from iPhone/iPad Chrome user agents, especially bulk reads, impossible travel, replays, or consent changes. This is your best practical detective layer because network exploit signatures are weak.
- Perimeter scanning doesn't help: this is not an exposed server vulnerability, so external attack-surface tools will miss it entirely.
- WAF rules don't solve the core issue: the browser is the vulnerable component, and attacker HTML can come from any allowed site or compromised content path.
- Network segmentation is mostly irrelevant: the exploit path is user browsing plus browser logic abuse, not lateral movement through internal ports.
Crowdsourced verification payload.
Run this on your auditor workstation, MDM export host, or CI job against a CSV export of mobile app inventory — not on the iPhone itself. Invoke it as python3 check_chrome_ios_cve_2026_11298.py devices.csv with no special privileges; the CSV should include at least one of these columns: bundle_id, app_name, platform, version, device_id.
#!/usr/bin/env python3
# check_chrome_ios_cve_2026_11298.py
#
# Determine whether managed devices are vulnerable to CVE-2026-11298
# based on Chrome for iOS app version inventory.
#
# Expected CSV columns (case-insensitive, any subset that helps):
# device_id, device_name, platform, bundle_id, app_name, version
#
# Logic:
# - Only rows that appear to be Google Chrome on iOS are evaluated.
# - Version < 149.0.7827.53 => VULNERABLE
# - Version >= 149.0.7827.53 => PATCHED
# - Missing/invalid version or no matching rows => UNKNOWN
#
# Exit codes:
# 0 = PATCHED
# 1 = VULNERABLE
# 2 = UNKNOWN / usage / parse issues
import csv
import re
import sys
from pathlib import Path
FIXED_VERSION = (149, 0, 7827, 53)
IOS_HINTS = {"ios", "ipados", "iphone", "ipad"}
CHROME_BUNDLE_IDS = {
"com.google.chrome.ios",
"com.google.chrome.ios.beta",
}
def norm(s):
return (s or "").strip().lower()
def parse_version(text):
if not text:
return None
nums = re.findall(r"\d+", text)
if not nums:
return None
parts = [int(x) for x in nums[:4]]
while len(parts) < 4:
parts.append(0)
return tuple(parts)
def is_ios_row(row):
platform = norm(row.get("platform", ""))
if any(h in platform for h in IOS_HINTS):
return True
return False
def is_chrome_ios_row(row):
bundle_id = norm(row.get("bundle_id", ""))
app_name = norm(row.get("app_name", ""))
platform = norm(row.get("platform", ""))
bundle_match = bundle_id in CHROME_BUNDLE_IDS or bundle_id.startswith("com.google.chrome.ios")
name_match = ("chrome" in app_name and "google" in app_name) or app_name == "chrome"
ios_match = any(h in platform for h in IOS_HINTS) or bundle_match
return ios_match and (bundle_match or name_match)
def compare_versions(a, b):
return (a > b) - (a < b)
def main():
if len(sys.argv) != 2:
print("UNKNOWN - usage: python3 check_chrome_ios_cve_2026_11298.py <inventory.csv>")
sys.exit(2)
csv_path = Path(sys.argv[1])
if not csv_path.exists():
print(f"UNKNOWN - file not found: {csv_path}")
sys.exit(2)
vulnerable = []
patched = []
unknown = []
matched_any = False
try:
with csv_path.open("r", encoding="utf-8-sig", newline="") as fh:
reader = csv.DictReader(fh)
if not reader.fieldnames:
print("UNKNOWN - CSV has no header row")
sys.exit(2)
# normalize headers
reader.fieldnames = [norm(h) for h in reader.fieldnames]
for raw_row in reader:
row = {norm(k): (v or "").strip() for k, v in raw_row.items()}
if not is_chrome_ios_row(row):
continue
matched_any = True
device = row.get("device_id") or row.get("device_name") or "unknown-device"
version_text = row.get("version", "")
version = parse_version(version_text)
if version is None:
unknown.append((device, version_text or "<missing>"))
continue
if compare_versions(version, FIXED_VERSION) < 0:
vulnerable.append((device, version_text))
else:
patched.append((device, version_text))
except Exception as exc:
print(f"UNKNOWN - failed to parse CSV: {exc}")
sys.exit(2)
if not matched_any:
print("UNKNOWN - no Chrome for iOS rows found in inventory")
sys.exit(2)
if vulnerable:
print(f"VULNERABLE - {len(vulnerable)} device(s) with Chrome for iOS below 149.0.7827.53")
for device, version in vulnerable[:25]:
print(f" {device}: {version}")
if len(vulnerable) > 25:
print(f" ... and {len(vulnerable) - 25} more")
if unknown:
print(f" NOTE: {len(unknown)} matching device(s) had unknown version data")
sys.exit(1)
if patched and not unknown:
print(f"PATCHED - {len(patched)} Chrome for iOS device(s) are at or above 149.0.7827.53")
sys.exit(0)
print(
f"UNKNOWN - no vulnerable versions found, but {len(unknown)} matching device(s) have missing/invalid version data"
)
for device, version in unknown[:25]:
print(f" {device}: {version}")
sys.exit(2)
if __name__ == "__main__":
main()
If you remember one thing.
Sources
- CVE summary feed for CVE-2026-11298
- Chrome Stable for iOS 149 release post
- Chrome 149 early stable desktop build 149.0.7827.53/.54
- Chromium iOS web layer architecture (`WKWebView` wrapper)
- Apple BrowserEngineKit overview
- Apple browser choice / browser app context on iOS
- CISA Known Exploited Vulnerabilities catalog
- FIRST EPSS project
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.