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.
4 steps from start to impact.
Land the victim in Chrome for iOS
- 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
- 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
Trigger the policy bypass with crafted HTML
- 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
- 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
Abuse the resulting browser-level access
- The bypass meaningfully changes what the attacker can do in the browser session
- The targeted user has relevant authenticated browser state or workflow value
- 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
Convert the browser win into something useful
- The victim session has meaningful access
- The attacker can chain the bypass into a business-relevant workflow
- 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
The supporting signals.
| In-the-wild status | No active exploitation evidence found in the sources reviewed; not KEV-listed. |
|---|---|
| Proof-of-concept availability | No public PoC located. Chromium issue references exist for many Chrome CVEs, but bug details are commonly restricted until patch adoption catches up. |
| EPSS | 0.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 status | No — not present in CISA's Known Exploited Vulnerabilities catalog as of the reviewed catalog source. |
| CVSS vector readout | CVSS: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 versions | Chrome for iOS < 149.0.7827.53. |
| Fixed version | 149.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 reality | Not 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 date | 2026-06-05 from the user-supplied intel; related Chrome 149 security advisories landed in early June 2026. |
| Reporter / credit | Not publicly attributable from the reviewed sources. Available advisory surfaces did not expose a named reporter for this specific CVE. |
noisgate verdict.
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.
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.
What to do — in priority order.
- Force App Store update compliance — Use MDM or enterprise mobility management to identify Chrome for iOS versions below
149.0.7827.53and 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. - 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.
- 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.
- 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.
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.
#!/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()
If you remember one thing.
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
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.