← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-11277 · 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 inside a locked phone app, not a hole blown through the perimeter

CVE-2026-11277 is an *insufficient policy enforcement* flaw in Chrome for iOS affecting versions before 149.0.7827.53. Per the supplied CVSS and title, the practical outcome is a remote attacker getting a user to open a crafted page in Chrome on an iPhone or iPad and then bypassing a browser-enforced discretionary access control check; this is an *integrity-only* browser-behavior issue, not code execution and not a device compromise.

Google's MEDIUM 4.3 baseline is already restrained, and I'd still push it *down* for enterprise patch triage. The attack requires the victim to be on the right client platform, using the Chrome app specifically on iOS, and to interact with attacker content; meanwhile the known impact is limited, EPSS is near-zero, KEV is negative, and there is no evidence this escapes iOS/WebKit sandboxing or creates broad lateral blast radius.

"Remote on paper, but this is a user-driven iOS browser policy bypass with narrow blast radius and no exploit heat"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the victim in Chrome for iOS

The attacker needs a delivery mechanism such as phishing, malvertising, or an in-app message to get the user to open a crafted URL in Chrome for iOS. Weaponization here is a simple malicious landing page; no exploit kit or memory corruption chain is needed based on the published description.
Conditions required:
  • Target uses an iPhone or iPad
  • Target has Google Chrome installed
  • Target opens the attacker-controlled page in Chrome rather than Safari or another browser
Where this breaks in practice:
  • This is a *client-side* path, so there is no server to scan for broad exposure
  • Many enterprises have mixed mobile-browser usage, shrinking reachable population
  • Email gateway, mobile threat defense, Safe Browsing, and user behavior all reduce delivery success
Detection/coverage: Network scanners will miss this entirely. Detection is mostly indirect via phishing telemetry, web proxy logs, MTD alerts, or managed-browser/App Store version inventory.
STEP 02

Trigger the policy bypass with crafted HTML

The attacker serves crafted HTML/JavaScript that exercises the insufficient policy enforcement condition in Chrome for iOS. The weaponized artifact is the page itself; no public PoC repository was found in the available sources.
Conditions required:
  • Victim renders attacker-controlled content
  • The vulnerable code path exists in the installed Chrome for iOS version
  • The target action relies on the affected policy boundary
Where this breaks in practice:
  • The bug class suggests narrow logic abuse rather than universal browser takeover
  • Available advisories do not show a renderer-to-OS escape or privilege elevation
  • Because bug details are restricted, exploitation reliability in the wild is unproven
Detection/coverage: Signature-based detection is weak without a public PoC. Browser crash telemetry is unlikely to help because this is described as policy enforcement failure, not memory corruption.
STEP 03

Abuse the resulting browser-level access

If successful, the attacker gets whatever unauthorized action the bypass permits inside Chrome's intended security model. Based on the vendor vector, that means low integrity impact with no stated confidentiality or availability impact, so think content manipulation or unauthorized browser action rather than data-theft-at-scale or device control.
Conditions required:
  • The bypass meaningfully changes what the attacker can do in the browser session
  • The targeted user has relevant authenticated browser state or workflow value
Where this breaks in practice:
  • CVSS says C:N/I:L/A:N, which is a small blast radius by design
  • iOS app sandboxing and WebKit platform constraints cap post-exploit options
  • There is no indication this gives persistent foothold on the handset
Detection/coverage: Look for suspicious navigation chains, web session anomalies, or help-desk reports of odd browser behavior. Standard EDR visibility on iOS is limited.
STEP 04

Convert the browser win into something useful

The attacker still has to turn a limited browser policy bypass into business impact, such as session abuse, spoofed UI flow, or a user-driven follow-on action. That conversion step is where many medium browser bugs die in real environments.
Conditions required:
  • The victim session has meaningful access
  • The attacker can chain the bypass into a business-relevant workflow
Where this breaks in practice:
  • Requires a high-value mobile browsing workflow to matter
  • MFA, conditional access, and app-based auth reduce downstream value
  • No active exploitation evidence suggests attackers do not currently find this chain worth scaling
Detection/coverage: Identity telemetry, impossible travel, anomalous session reuse, and web application logs are more useful than vulnerability scanners here.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo active exploitation evidence found in the sources reviewed; not KEV-listed.
Proof-of-concept availabilityNo public PoC located. Chromium issue references exist for many Chrome CVEs, but bug details are commonly restricted until patch adoption catches up.
EPSS0.0002 from the user-supplied intel, which is effectively background noise for enterprise prioritization; that implies an extremely low modeled near-term exploitation probability.
KEV statusNo — not present in CISA's Known Exploited Vulnerabilities catalog as of the reviewed catalog source.
CVSS vector readoutCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N means remote and easy to trigger *if* you can get user interaction, but the actual impact is only low integrity with no stated confidentiality or availability loss.
Affected versionsChrome for iOS < 149.0.7827.53.
Fixed version149.0.7827.53. On iOS, updates ride through the Apple App Store and can be accelerated through MDM/App Store management rather than desktop patch tooling.
Exposure realityNot internet-addressable in the normal sense. There is no meaningful Shodan/Censys/FOFA population to count because the vulnerable surface is a *mobile client app*, not a listening enterprise service; that is an inference from the product architecture.
Disclosure date2026-06-05 from the user-supplied intel; related Chrome 149 security advisories landed in early June 2026.
Reporter / creditNot publicly attributable from the reviewed sources. Available advisory surfaces did not expose a named reporter for this specific CVE.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (2.9/10)

The decisive downward pressure is that this is a Chrome-for-iOS client-side policy bypass with required user interaction and only low integrity impact. It is not an enterprise edge-service bug, not a code-execution bug, and not backed by KEV, public PoC, or meaningful exploitation probability.

HIGH Affected version range and fixed version
MEDIUM Real-world exploitability assessment from sparse public bug detail

Why this verdict

  • Downshift for platform reach: attacker must hit *Chrome on iOS specifically*, which implies only the mobile slice of your fleet and not your whole browser estate
  • Downshift for user interaction: the chain starts with convincing a user to open crafted content, so secure email, Safe Browsing, and normal user variance all cut real exploit success
  • Downshift for impact: the vendor vector is C:N/I:L/A:N, meaning limited browser-level integrity impact rather than data theft, code execution, or device takeover
  • Downshift for exposure model: this is not a remotely scannable enterprise service; it is a client app bug with no Shodan-style exposure population to mass-target
  • Downshift for threat intel: EPSS is near zero, KEV is negative, and no public PoC or campaign reporting was found

Why not higher?

If this were a browser memory-corruption bug with code execution, or if it were already in KEV, the call would jump fast. But the available facts point to a logic/policy failure on one mobile browser platform with required user interaction and only low stated impact.

Why not lower?

I would not mark it IGNORE because it is still a remotely triggerable browser flaw in a mainstream app and can matter for sensitive mobile workflows. If you manage regulated or executive mobile users who browse in Chrome on iOS, there is enough residual risk to keep it in normal hygiene queues.

05 · Compensating Control

What to do — in priority order.

  1. Force App Store update compliance — Use MDM or enterprise mobility management to identify Chrome for iOS versions below 149.0.7827.53 and push users onto the current release. For a LOW verdict there is no fixed noisgate SLA; treat this as backlog hygiene and fold it into your normal mobile app update cycle.
  2. Reduce risky mobile link delivery — Tune email, messaging, and mobile threat defense controls to reduce phishing and malicious-link opens on iOS, because the exploit path starts with user navigation. Again, LOW means no hard mitigation deadline; implement as part of standard mobile hardening rather than emergency change.
  3. Prefer managed browser telemetry — If you standardize on managed mobile browsing, collect inventory and policy telemetry so you can prove version coverage instead of guessing. For this severity, focus on operational visibility instead of disruptive emergency controls.
What doesn't work
  • A perimeter WAF does not solve a client-side browser logic flaw; the vulnerable component is the user's app behavior.
  • External vulnerability scanning will not find this because phones running Chrome for iOS are not exposed as listening services.
  • Desktop Chrome patching does not address it; this is scoped to Chrome for iOS.
06 · Verification

Crowdsourced verification payload.

Run this on an auditor workstation or MDM reporting host, not on the iPhone itself. Export your mobile app inventory to CSV and invoke it as python3 check_cve_2026_11277.py mobile_apps.csv; no admin rights are needed, but the CSV must include device/app/version columns such as device_name,app_name,app_version or device_name,bundle_id,version.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_cve_2026_11277.py
# Determine exposure to CVE-2026-11277 from an MDM/exported mobile app inventory CSV.
# Outputs one overall status: VULNERABLE / PATCHED / UNKNOWN
# Exit codes:
#   0 = PATCHED (all detected Chrome for iOS installs are >= 149.0.7827.53)
#   1 = VULNERABLE (at least one detected Chrome for iOS install is < 149.0.7827.53)
#   2 = UNKNOWN (no usable Chrome for iOS rows found or version parsing failed)

import csv
import sys
import re

FIXED = (149, 0, 7827, 53)
CHROME_NAMES = {
    'google chrome',
    'chrome',
    'chrome for ios'
}
CHROME_BUNDLES = {
    'com.google.chrome.ios',
    'com.google.chrome'
}


def norm(s):
    return (s or '').strip().lower()


def parse_version(v):
    if not v:
        return None
    nums = re.findall(r'\d+', str(v))
    if not nums:
        return None
    parts = tuple(int(x) for x in nums[:4])
    if len(parts) < 4:
        parts = parts + (0,) * (4 - len(parts))
    return parts


def version_lt(a, b):
    return a < b


def pick(row, candidates):
    for c in candidates:
        if c in row and row[c] not in (None, ''):
            return row[c]
    return ''


def is_chrome_ios(row):
    app_name = norm(pick(row, ['app_name', 'application', 'name', 'app']))
    bundle_id = norm(pick(row, ['bundle_id', 'package', 'package_name', 'bundle']))
    platform = norm(pick(row, ['platform', 'os', 'device_os']))

    name_match = app_name in CHROME_NAMES or ('chrome' in app_name and 'ios' in app_name)
    bundle_match = bundle_id in CHROME_BUNDLES
    ios_hint = ('ios' in platform) or ('iphone' in platform) or ('ipad' in platform) or platform == ''

    return ios_hint and (name_match or bundle_match)


def main():
    if len(sys.argv) != 2:
        print('UNKNOWN - usage: python3 check_cve_2026_11277.py <inventory.csv>')
        sys.exit(2)

    path = sys.argv[1]
    vulnerable = []
    patched = []
    unknown = []
    matched_rows = 0

    try:
        with open(path, newline='', encoding='utf-8-sig') as f:
            reader = csv.DictReader(f)
            if not reader.fieldnames:
                print('UNKNOWN - CSV has no headers')
                sys.exit(2)

            for row in reader:
                if not is_chrome_ios(row):
                    continue

                matched_rows += 1
                device = pick(row, ['device_name', 'hostname', 'device', 'name', 'serial_number']) or 'unknown-device'
                version_raw = pick(row, ['app_version', 'version', 'application_version'])
                version = parse_version(version_raw)

                if version is None:
                    unknown.append((device, version_raw))
                elif version_lt(version, FIXED):
                    vulnerable.append((device, version_raw))
                else:
                    patched.append((device, version_raw))

    except FileNotFoundError:
        print(f'UNKNOWN - file not found: {path}')
        sys.exit(2)
    except Exception as e:
        print(f'UNKNOWN - failed to read CSV: {e}')
        sys.exit(2)

    if vulnerable:
        print('VULNERABLE')
        print(f'Affected Chrome for iOS installs below 149.0.7827.53: {len(vulnerable)}')
        for device, version in vulnerable[:50]:
            print(f'  {device}: {version}')
        if len(vulnerable) > 50:
            print(f'  ... {len(vulnerable) - 50} more')
        sys.exit(1)

    if matched_rows == 0:
        print('UNKNOWN - no Chrome for iOS rows found in inventory')
        sys.exit(2)

    if unknown and not patched:
        print('UNKNOWN')
        print(f'Chrome for iOS rows found, but version could not be parsed for {len(unknown)} device(s)')
        for device, version in unknown[:50]:
            print(f'  {device}: {version}')
        sys.exit(2)

    print('PATCHED')
    print(f'Patched Chrome for iOS installs at or above 149.0.7827.53: {len(patched)}')
    if unknown:
        print(f'Warning: version unknown on {len(unknown)} additional device(s)')
    sys.exit(0)


if __name__ == '__main__':
    main()
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, do not let this elbow its way ahead of remotely exploitable edge bugs or browser RCEs. For a LOW verdict there is no noisgate mitigation SLA and no noisgate remediation SLA — treat it as backlog hygiene: identify Chrome for iOS installs below 149.0.7827.53, fold them into the next normal mobile-app update cycle, and document any high-sensitivity mobile user groups where you want faster cleanup anyway.

Sources

  1. openSUSE patchinfo for Chromium 149 security fixes
  2. Chrome Releases blog
  3. Google Chrome Help - Update Chrome on iPhone and iPad
  4. CISA Known Exploited Vulnerabilities Catalog
  5. FIRST EPSS overview
  6. FIRST EPSS API documentation
  7. Canadian Centre for Cyber Security advisory for Chrome 149 desktop fixes
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.