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

Inappropriate implementation 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 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.

"Real bug, but it needs a user on Chrome for iOS and only buys per-user web-session abuse."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the victim on attacker HTML

The attacker needs a user running vulnerable Chrome for iOS to load a crafted page. Delivery is the usual browser initial-access path: phishing link, ad traffic, compromised site, or in-app browser handoff into Chrome.
Conditions required:
  • Victim uses Google Chrome on iOS
  • Installed version is prior to 149.0.7827.53
  • Victim opens attacker-controlled or attacker-influenced content
Where this breaks in practice:
  • 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
Detection/coverage: Traditional vuln scanners have poor coverage for mobile app build state unless fed by MDM/EMM inventory. Network IDS generally will not signature this reliably because the exploit is browser-logic abuse, not a stable wire pattern.
STEP 02

Break the browser origin boundary

The crafted page triggers the Chrome-for-iOS implementation flaw and bypasses same-origin restrictions. Weaponized content is just HTML/JS; no authentication or device compromise is required at this stage beyond getting the page rendered in the vulnerable app.
Conditions required:
  • The vulnerable code path is reachable from web content
  • Browser-side mitigations do not block the specific SOP bypass primitive
Where this breaks in practice:
  • 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
Detection/coverage: Exploit validation coverage is weak. This class is usually found by browser vendor testing, security research, or post-incident client telemetry rather than commodity scanning.
STEP 03

Read or drive cross-origin web state

Once the origin boundary is bypassed, the attacker can target data or actions tied to the victim's authenticated browser session in Chrome for iOS. Practical impact is usually cross-site data theft, token/session abuse, or unauthorized web actions against sites the victim already has open or authenticated.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Look for anomalous web actions in SaaS audit logs from mobile user agents, but there is no dependable CVE-specific artifact.
STEP 04

Exfiltrate session-bound data

The attacker sends harvested data off-box or uses the victim's session to perform targeted actions. That can matter for sensitive portals, but it is still a single-user browser-session problem rather than a fleet-wide remote foothold.
Conditions required:
  • Attacker has a collection endpoint or action objective
  • Enterprise data is accessible through the victim's browser session
Where this breaks in practice:
  • 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
Detection/coverage: Primary signal is downstream: impossible travel, suspicious SaaS/API actions, or unusual data access tied to affected mobile sessions.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public exploitation evidence found as of 2026-06-08; not KEV-listed.
PoC availabilityNo public PoC or weaponized exploit repo found in current public search results. Treat as *researcher/private-only* until proven otherwise.
EPSS0.0001 from the user-provided intel, which is effectively floor-level exploit probability.
KEV statusNo. CISA KEV does not currently list this CVE.
CVSS vector meaningCVSS: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 versionsChrome for iOS prior to 149.0.7827.53.
Fixed version149.0.7827.53 or later. On iOS this lands through the App Store / MDM app update path, not OS package management.
Exposure realityShodan/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 architectureChrome'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 metadataDisclosed 2026-06-05. Public researcher credit was not found in the accessible advisories.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (3.8/10)

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.

HIGH Downgrade based on attack-path friction and lack of exploitation evidence
MEDIUM Exact exploit mechanics, because Google has not published full technical details

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.

05 · Compensating Control

What to do — in priority order.

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

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.

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

If you remember one thing.

TL;DR
Monday morning: query your MDM for Chrome on iOS inventory, identify devices below 149.0.7827.53, and push the app update through your normal mobile app workflow. Because this is LOW, there is no noisgate mitigation SLA and you should go straight to the backlog-style remediation window; use the noisgate remediation SLA as backlog hygiene, but in practice close it much sooner if you have sensitive mobile SaaS users or executives carrying authenticated browser sessions.

Sources

  1. CVE summary feed for CVE-2026-11298
  2. Chrome Stable for iOS 149 release post
  3. Chrome 149 early stable desktop build 149.0.7827.53/.54
  4. Chromium iOS web layer architecture (`WKWebView` wrapper)
  5. Apple BrowserEngineKit overview
  6. Apple browser choice / browser app context on iOS
  7. CISA Known Exploited Vulnerabilities catalog
  8. FIRST EPSS project
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.