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

Inappropriate implementation in DOM Distiller in Google Chrome on iOS prior to 149

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

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.

"Remote but niche: this is a user-clicked Chrome iOS reader-mode navigation bypass, not an enterprise fire drill"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Deliver a lure URL

The attacker needs a victim to open a crafted web page in Chrome on iOS. The practical weapon is just a phishing link delivered over email, chat, SMS, or an enterprise app deep link; there is no public exploit kit or mass-scan signature associated with this CVE.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Email/SMS security can see the lure, but vulnerability scanners will not meaningfully detect this from the network edge.
STEP 02

Reach the DOM Distiller path

The malicious page then has to trigger the vulnerable DOM Distiller / Reader Mode logic. DOM Distiller is not the mainline rendering engine path; it is reader-mode content distillation logic used to simplify article-style pages, which materially narrows the reachable population compared with a generic browser-core bug.
Conditions required:
  • 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
Where this breaks in practice:
  • 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'
Detection/coverage: No reliable scanner coverage expected; at best, MDM inventory can identify vulnerable app versions.
STEP 03

Bypass intended navigation restrictions

Once the vulnerable code path is reached, the attacker can allegedly bypass navigation restrictions and redirect or open destinations that the browser should have constrained. The likely abuse case is forced or misleading navigation, including brand spoofing, fake login flow steering, or pushing the user into an unexpected browser/app context.
Conditions required:
  • The crafted HTML successfully exercises the vulnerable logic
  • The victim follows the resulting flow rather than abandoning it
Where this breaks in practice:
  • Published impact is only integrity-low; no confidentiality or availability impact is claimed
  • No public write-up shows a reliable post-bypass escalation chain
Detection/coverage: Browser telemetry, Safe Browsing, URL filtering, and mobile threat defense may catch the downstream malicious destination, but not the underlying bug.
STEP 04

Turn confusion into phishing value

The attacker still needs a second-stage objective: credential collection, consent phishing, or app-switch trickery. In other words, this CVE is not the breach by itself; it is a helper that can make a social-engineering flow cleaner or more convincing on affected devices.
Conditions required:
  • Target has accounts or sessions worth stealing
  • Victim interacts with the spoofed or redirected content
Where this breaks in practice:
  • 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
Detection/coverage: Identity telemetry and phishing-resistant MFA provide better downstream visibility than vuln scanning does upstream.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo active exploitation evidence found in the reviewed sources, and not listed in CISA KEV as of 2026-06-07
Public PoCNo public PoC or exploit repo found during review; no researcher blog or GitHub weaponization was located
EPSS0.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 statusNot KEV-listed; therefore no federal due date or emergency patch pressure signal
CVSS meaningAV: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 versionsChrome on iOS < 149.0.7827.53
Fixed versionsChrome 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 realityNot internet-addressable. Shodan/Censys-style exposure counts are basically irrelevant because this is a client-side mobile browser bug, not a listening service
Disclosure date2026-06-05
Researcher / reportingNot publicly attributed in the sources reviewed; Chrome's public metadata names the component but not a finder
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (2.9/10)

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.

MEDIUM Severity downgrade from vendor MEDIUM to LOW
HIGH No internet-exposed server-side blast radius
MEDIUM Assessment that DOM Distiller is a niche code path on managed fleets

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.

05 · Compensating Control

What to do — in priority order.

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

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.

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

If you remember one thing.

TL;DR
On Monday morning, do not burn an emergency window on this one. Add a minimum-version check for Chrome on iOS 149.0.7827.53+ to your MDM app inventory, let normal mobile auto-update policy clear out stragglers, and document any exceptions. For a LOW verdict there is no noisgate mitigation SLA and no noisgate remediation SLA beyond backlog hygiene, so this belongs in routine mobile patch maintenance rather than a special response queue.

Sources

  1. SUSE CVE page for CVE-2026-11274
  2. openSUSE patchinfo listing Chromium 149 fixes including CVE-2026-11274
  3. Chrome Stable for iOS Update 149.0.7827.45
  4. Chrome Releases homepage showing 149.0.7827.53/.54 early stable rollout
  5. Chromium DOM Distiller README
  6. Chromium layered components design note for iOS shared-code constraints
  7. CISA Known Exploited Vulnerabilities Catalog
  8. FIRST EPSS API documentation
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.