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

Insufficient policy enforcement 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 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.

"This is a niche policy-bypass bug in a client-side iOS browser, not a fleet-wide fire drill"
02 · The Attack Path

3 steps from start to impact.

STEP 01

Land a user on vulnerable Chrome for iOS

The attacker needs a target using Chrome for iOS < 149.0.7827.53 and must get that user to open attacker-controlled web content. The practical weapon here is just a malicious HTML/JS landing page; no public exploit kit or repo was found. This is classic client-side delivery, but on mobile it is gated by app choice, version drift, and user behavior.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: MDM/mobile app inventory can identify vulnerable app versions; network scanners cannot meaningfully detect this because it is a client-side iOS app issue.
STEP 02

Trigger the policy-enforcement gap

Once the page loads, the attacker abuses the policy enforcement weakness using a crafted HTML page to bypass a browser-level access control decision. Based on the description, this is not a memory corruption path; it is a logic flaw that lets content reach a state the browser should have denied. No public PoC or bug-thread details were available, so exploitation mechanics remain inferred from the CVE text.
Conditions required:
  • The vulnerable code path is reachable from normal web content
  • The relevant access-control or enterprise policy check is active in that browsing context
Where this breaks in practice:
  • 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
Detection/coverage: There is no strong signature-based scanner coverage for the exploit path itself. Logging may only show a normal page visit unless you have Chrome enterprise telemetry on managed iOS.
STEP 03

Abuse the bypassed control

The attacker then uses the bypass to perform an action the app should have blocked, likely around navigation or access-control behavior inside Chrome for iOS. The reported impact is only I:L in the supplied CVSS vector, which aligns with a constrained, app-scoped policy escape rather than broad data theft or code execution. In practice, this is an integrity issue against browser controls, not a direct path to device takeover.
Conditions required:
  • The bypassed control protects a workflow the attacker can immediately benefit from
  • The user remains in session long enough for follow-on abuse
Where this breaks in practice:
  • No evidence of persistence, sandbox escape, or OS-level compromise
  • Blast radius appears limited to the browser app and possibly the managed profile context
Detection/coverage: Best detected indirectly through policy exception telemetry, unusual managed-browser navigation events, or user reports of blocked content unexpectedly opening.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo active exploitation evidence found. Not present in CISA KEV as of 2026-06-05.
Public PoCNone found publicly in vendor references or common exploit-tracking sources at time of review.
EPSS0.0002 — effectively floor-level exploit probability; this matches the weak attacker economics of a niche client-side logic flaw.
KEV statusNot KEV-listed; no due date pressure from exploitation evidence.
CVSS vectorCVSS: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 versionsChrome for iOS before 149.0.7827.53.
Fixed version149.0.7827.53 or later. Because this is an App Store-delivered mobile app, remediation is an app update, not an OS patch.
Exposure realityNot internet-enumerable. Shodan/Censys-style exposure data is basically irrelevant here because this is a client-side iOS app, not a listening service.
Platform nuanceOn 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 / attributionDisclosed 2026-06-05. Public reporting credit was not clearly attributed in the accessible references.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (3.1/10)

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.

MEDIUM Severity downgrade from vendor MEDIUM to LOW
LOW Exact exploit mechanics, because public technical detail is sparse
HIGH No evidence of KEV listing or public exploitation as of 2026-06-05

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.

05 · Compensating Control

What to do — in priority order.

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

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.

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

If you remember one thing.

TL;DR
Monday morning: query your MDM/UEM inventory for Chrome for iOS versions below 149.0.7827.53, update the stragglers in the next routine mobile app cycle, and document whether any business-critical iOS population actually depends on Chrome policy enforcement. Because this is LOW, the noisgate mitigation SLA is no SLA (treat as backlog hygiene), and the noisgate remediation SLA is likewise backlog hygiene rather than a date-driven emergency; if you find a tightly controlled managed-iOS user group depending on Chrome browser policies, prioritize them first inside your normal change window.

Sources

  1. CVE alert summary for CVE-2026-11302
  2. Chrome Stable for iOS Update 149.0.7827.45
  3. Google Chrome for iOS App Store listing
  4. Apple App Review Guidelines
  5. Turn on Chrome browser management (Android and iOS)
  6. Set Chrome policies for users or browsers
  7. FIRST EPSS overview
  8. CISA Known Exploited Vulnerabilities Catalog
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.