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

Inappropriate implementation in Signin in Google Chrome on iOS prior to 149

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

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.

"Remote webpage bug, but it lives in iOS Chrome signin UX and needs a user click—patch it, don’t panic"
02 · The Attack Path

3 steps from start to impact.

STEP 01

Deliver a malicious page

The attacker needs the victim to open a crafted HTML page in Chrome on iOS. The practical weapon is just a lure URL delivered through email, chat, SMS, or a web redirect; no public exploit kit or turnkey PoC was found in the sources reviewed.
Conditions required:
  • Victim uses Chrome on iOS, not another browser
  • Installed app version is earlier than 149.0.7827.53
  • Victim opens attacker-controlled content
Where this breaks in practice:
  • Requires a real user click path
  • Population is limited to iOS Chrome users
  • Managed mobile fleets often auto-update apps quickly
Detection/coverage: Traditional vuln scanners do not see this well; detection is mainly MDM app inventory plus phishing telemetry.
STEP 02

Trigger the Signin navigation bypass

The page abuses the vulnerable 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.
Conditions required:
  • Victim reaches the affected sign-in or related navigation path
  • Attacker-controlled page can invoke the relevant browser behavior
Where this breaks in practice:
  • 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
Detection/coverage: No reliable network signature is likely; browser crash telemetry is irrelevant because this is not described as a crash/RCE bug.
STEP 03

Abuse trust in the altered flow

If exploitation succeeds, the attacker can influence where the user is allowed to navigate during a sign-in-related flow, enabling spoofing, misleading redirects, or policy bypass inside the app context. The security impact is mainly integrity of the browsing/sign-in experience, not host takeover.
Conditions required:
  • User trusts the resulting page or flow enough to continue
  • The bypass meaningfully changes a sign-in journey or restricted destination
Where this breaks in practice:
  • 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
Detection/coverage: Best coverage is from identity telemetry: suspicious OAuth consent, odd mobile user-agents, and abnormal sign-in sequences.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence of active exploitation found in the reviewed sources, and it is not listed in CISA KEV.
PoC availabilityNo public PoC or weaponized GitHub repo found. The linked Chromium issue is still access-restricted, which usually slows copycat exploitation.
EPSS0.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 statusNot KEV-listed as checked against the CISA Known Exploited Vulnerabilities Catalog after disclosure on 2026-06-04.
CVSS meaningCVSS: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 versionsChrome 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 version149.0.7827.53 or later. For enterprise, trust MDM-reported app version rather than user screenshots.
Exposure / scanning realityNot 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 / reportingPublished 2026-06-04 by Chrome; Google credits the bug internally as reported by Google on 2026-04-22 in the Chrome 149 advisory.
Platform containmentGoogle documents that Chrome on iOS uses Apple's WKWebView, which materially limits exploit primitives compared with full desktop Chrome.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (3.9/10)

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.

HIGH Affected version boundary and vendor metadata
MEDIUM Real-world exploitability downgrade versus vendor CVSS

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:R is 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.

05 · Compensating Control

What to do — in priority order.

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

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.

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

If you remember one thing.

TL;DR
Monday morning, have the mobile team pull an MDM inventory for Chrome on iOS and identify anything below 149.0.7827.53. There is no noisgate mitigation SLA and noisgate remediation SLA for a LOW finding—treat this as backlog hygiene, not an emergency—but do fold the stale versions into your next routine mobile app update wave and document the rationale for not fast-tracking: iOS-only, user-click required, no KEV, no public exploit, and impact bounded to browser sign-in/navigation integrity.

Sources

  1. NVD entry for CVE-2026-11204
  2. Chrome 149 stable channel advisory listing CVE-2026-11204
  3. Chromium issue 505200733 referenced by the CVE
  4. Chrome stable for iOS 149.0.7827.45 release note
  5. Google Help note that Chrome on iOS uses WKWebView
  6. CISA Known Exploited Vulnerabilities Catalog
  7. FIRST EPSS API documentation
  8. CVE record mirror showing affected version metadata
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.