This is a faulty hallway sign in the browser, not someone cutting a new door through the vault
CVE-2026-11274 is a navigation-restriction bypass in DOM Distiller — Chrome's reader-mode/distillation plumbing — affecting Google Chrome on iOS before 149.0.7827.53. A malicious page can apparently abuse that code path to steer navigation in ways Chrome intended to block, but the published description stops at bypass navigation restrictions via a crafted HTML page; there is no evidence here of code execution, sandbox escape, credential theft by itself, or cross-app compromise.
The vendor's MEDIUM 4.3 is already modest, but in enterprise reality this lands even lower. The friction stack is heavy: user interaction is required, the victim must be on Chrome for iOS specifically, the exploit has to hit the DOM Distiller/reader-mode path, and the stated impact is only integrity-low. That makes this a phishing/spoofing amplifier at worst, not a broad fleet-burner.
4 steps from start to impact.
Deliver a lure URL
- Victim uses Chrome on iOS, not Safari or another managed browser
- Victim is running a version earlier than 149.0.7827.53
- Victim clicks or opens attacker-controlled content
- UI:R means the attacker does not get a drive-by win against idle devices
- Mobile phishing controls, safe-link rewriting, and user training cut down clickthrough
- Many enterprises do not standardize on Chrome for iOS
Reach the DOM Distiller path
- The page structure must be suitable for the distillation workflow or otherwise hit the affected code path
- Chrome iOS build contains the vulnerable DOM Distiller implementation
- This is a feature-specific path, not every page-view path
- Real-world reliability is likely worse than the CVSS vector suggests because the feature gate is narrower than 'open any web page'
Bypass intended navigation restrictions
- The crafted HTML successfully exercises the vulnerable logic
- The victim follows the resulting flow rather than abandoning it
- Published impact is only integrity-low; no confidentiality or availability impact is claimed
- No public write-up shows a reliable post-bypass escalation chain
Turn confusion into phishing value
- Target has accounts or sessions worth stealing
- Victim interacts with the spoofed or redirected content
- Modern IdP defenses like MFA and risk-based login challenge the follow-on abuse
- Blast radius is per-user and per-device, not an enterprise-wide server-side foothold
The supporting signals.
| In-the-wild status | No active exploitation evidence found in the reviewed sources, and not listed in CISA KEV as of 2026-06-07 |
|---|---|
| Public PoC | No public PoC or exploit repo found during review; no researcher blog or GitHub weaponization was located |
| EPSS | 0.0002 per the user-supplied intel; that is effectively near-floor likelihood. *Percentile was not directly verified from FIRST in-browser during this review.* |
| KEV status | Not KEV-listed; therefore no federal due date or emergency patch pressure signal |
| CVSS meaning | AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N = remote and easy to trigger if a user opens malicious content, but only low integrity impact with no stated data loss or availability loss |
| Affected versions | Chrome on iOS < 149.0.7827.53 |
| Fixed versions | Chrome on iOS 149.0.7827.53+; downstream Linux packaging also shows backported coverage such as openSUSE chromium / chromedriver 149.0.7827.53-2.1 |
| Exposure reality | Not internet-addressable. Shodan/Censys-style exposure counts are basically irrelevant because this is a client-side mobile browser bug, not a listening service |
| Disclosure date | 2026-06-05 |
| Researcher / reporting | Not publicly attributed in the sources reviewed; Chrome's public metadata names the component but not a finder |
noisgate verdict.
The decisive factor is path friction: exploitation requires a user to open attacker content in Chrome on iOS and then reach the DOM Distiller/reader-mode flow, which is a much narrower population than a generic browser-core bug. On top of that, the published impact stays at integrity-low, so even a successful exploit is more likely to aid phishing than to hand over devices or data at scale.
Why this verdict
- Baseline down from 4.3 because UI:R matters: the attacker needs the victim to open crafted content, which removes the mass-drive-by value you worry about in fleet triage
- Further down because attacker reach is narrow: this is Chrome on iOS only, which already implies a subset of your mobile population and excludes desktops, Android, and Safari-heavy iPhone fleets
- Further down because the vulnerable path is feature-specific: DOM Distiller / Reader Mode is not the dominant browsing path, so the reachable population is smaller than the CVSS line item suggests
- Further down because impact is weak: the stated outcome is a navigation restriction bypass with I:L / C:N / A:N, not code execution, account takeover, or container escape
- No upward pressure from threat intel: no KEV listing, no public exploitation evidence, and an EPSS of 0.0002 all argue against emergency handling
Why not higher?
There is no evidence of RCE, sandbox escape, credential disclosure by default, or cross-device wormability. The exploit chain also assumes both user interaction and a niche feature path, which is exactly the kind of compounding friction that should keep a browser bug out of HIGH unless exploitation evidence shows otherwise.
Why not lower?
It is still a remote, user-triggerable browser flaw in a product some enterprises do manage on corporate iPhones. Even low-grade navigation control can improve phishing reliability, so this should not be hand-waved away as purely informational.
What to do — in priority order.
- Enforce minimum app version — Use MDM/App Store compliance to require Chrome iOS 149.0.7827.53+ on managed devices. For a LOW verdict there is no mitigation SLA and no formal remediation SLA beyond backlog hygiene, so fold this into the next normal mobile app enforcement cycle rather than creating emergency change debt.
- Keep phishing controls in front of mobile users — Safe-link rewriting, URL reputation, and mobile threat defense blunt the real abuse case here: luring users into malicious destinations after a navigation bypass. Because this is LOW, treat these as standing controls, not emergency-only measures.
- Monitor browser inventory by bundle ID and version — Inventory is the only scalable way to answer whether you actually have exposure, because network scanners cannot see into iPhone app versions. Add a recurring MDM check for the Chrome iOS bundle and version and clean up drift as backlog hygiene.
- Prefer phishing-resistant auth on mobile — If the bug is used as a redirect/spoofing helper, the follow-on kill chain is usually credential capture. Passkeys, FIDO2, and conditional access reduce the value of a prettier phishing page even when the browser is imperfect.
- Perimeter WAF/NGFW rules do not fix a client-side browser logic bug living inside an iOS app
- External vuln scanning will miss the real question, which is app version on devices rather than open TCP services
- Server EDR is irrelevant here; the target surface is the user's mobile browser session, not your servers
Crowdsourced verification payload.
Run this on an auditor workstation or MDM reporting host, not on the iPhone itself. Invoke it against a CSV export such as python3 check_chrome_ios_cve_2026_11274.py mdm_apps.csv; it needs no admin rights, only read access to the export. Expected columns can be any of: device_id, bundle_id, app_name, version.
#!/usr/bin/env python3
# Check exposure to CVE-2026-11274 in Chrome on iOS using an MDM/exported CSV
# Usage: python3 check_chrome_ios_cve_2026_11274.py mdm_apps.csv
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import csv
import re
import sys
from pathlib import Path
FIXED = (149, 0, 7827, 53)
IOS_CHROME_BUNDLES = {
'com.google.chrome.ios',
'com.google.chrome',
}
IOS_CHROME_NAMES = {
'chrome',
'google chrome',
'chrome for ios',
}
def norm(s):
return (s or '').strip().lower()
def parse_version(s):
if not s:
return None
nums = re.findall(r'\d+', s)
if len(nums) < 2:
return None
parts = tuple(int(x) for x in nums[:4])
if len(parts) < 4:
parts = parts + (0,) * (4 - len(parts))
return parts
def is_ios_chrome(row):
bundle = norm(row.get('bundle_id') or row.get('bundle') or row.get('package_id') or row.get('identifier'))
name = norm(row.get('app_name') or row.get('name') or row.get('application') or row.get('product'))
platform = norm(row.get('platform') or row.get('os') or row.get('operating_system'))
bundle_hit = bundle in IOS_CHROME_BUNDLES
name_hit = name in IOS_CHROME_NAMES
ios_hint = ('ios' in platform) or ('iphone' in platform) or ('ipad' in platform) or (bundle == 'com.google.chrome.ios')
if bundle_hit:
return True
if name_hit and ios_hint:
return True
return False
def device_label(row, index):
for key in ('device_id', 'device', 'hostname', 'serial', 'udid', 'user'):
if row.get(key):
return str(row.get(key))
return f'row_{index}'
def main():
if len(sys.argv) != 2:
print('UNKNOWN - usage: python3 check_chrome_ios_cve_2026_11274.py <mdm_csv_export>')
sys.exit(2)
path = Path(sys.argv[1])
if not path.exists() or not path.is_file():
print(f'UNKNOWN - file not found: {path}')
sys.exit(2)
checked = 0
vulnerable = []
unknown = []
try:
with path.open('r', encoding='utf-8-sig', newline='') as f:
reader = csv.DictReader(f)
if not reader.fieldnames:
print('UNKNOWN - CSV has no header row')
sys.exit(2)
for idx, row in enumerate(reader, start=2):
if not is_ios_chrome(row):
continue
checked += 1
ver_str = row.get('version') or row.get('app_version') or row.get('short_version') or row.get('installed_version')
ver = parse_version(ver_str)
label = device_label(row, idx)
if ver is None:
unknown.append((label, ver_str or ''))
continue
if ver < FIXED:
vulnerable.append((label, ver_str))
except Exception as e:
print(f'UNKNOWN - failed to parse CSV: {e}')
sys.exit(2)
if checked == 0:
print('UNKNOWN - no Chrome on iOS records found in CSV')
sys.exit(2)
if vulnerable:
sample = ', '.join(f'{d}={v}' for d, v in vulnerable[:10])
extra = '' if len(vulnerable) <= 10 else f' ... and {len(vulnerable) - 10} more'
print(f'VULNERABLE - {len(vulnerable)} Chrome iOS record(s) below 149.0.7827.53; sample: {sample}{extra}')
sys.exit(1)
if unknown:
sample = ', '.join(f'{d}={v}' for d, v in unknown[:10])
extra = '' if len(unknown) <= 10 else f' ... and {len(unknown) - 10} more'
print(f'UNKNOWN - {checked} Chrome iOS record(s) found, but {len(unknown)} version value(s) could not be parsed; sample: {sample}{extra}')
sys.exit(2)
print(f'PATCHED - {checked} Chrome iOS record(s) are at or above 149.0.7827.53')
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
Sources
- SUSE CVE page for CVE-2026-11274
- openSUSE patchinfo listing Chromium 149 fixes including CVE-2026-11274
- Chrome Stable for iOS Update 149.0.7827.45
- Chrome Releases homepage showing 149.0.7827.53/.54 early stable rollout
- Chromium DOM Distiller README
- Chromium layered components design note for iOS shared-code constraints
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS API documentation
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.