Use after free in WebMIDI in Google Chrome on iOS prior to 149

CVE-2026-11165 is a reported use-after-free in WebMIDI affecting Google Chrome on iOS before 149.0.7827.53, with the vendor describing possible sandbox escape from a crafted web page. In abstract browser-bug terms that is ugly: remote delivery, no prior auth, and memory corruption in a browser component is exactly the class of issue that can turn into code execution or a privilege boundary bypass.

In practice, the vendor's CRITICAL 9.6 overstates enterprise risk for normal iOS fleets. Chrome on iOS is generally constrained by Apple's WebKit rules, and Web MIDI is not supported on Safari/iOS WebKit, which means the named feature path is largely non-reachable in standard App Store deployments. Add the need for user interaction and the fact this is a client-side mobile-app issue with no internet-exposed service footprint, and this falls from emergency patching into backlog hygiene unless you have niche alternative-browser-engine pilots or regional exceptions.

Why this verdict

• Vendor baseline is theoretical, not deployed reality: 9.6 assumes the vulnerable path is reachable from hostile web content and can cross a sandbox boundary.
• Attacker position is worse than the CVSS headline suggests: they still need user interaction and a victim browsing event, which already removes this from wormable, server-side urgency.
• Reachability collapses on standard iOS: Apple App Store rules keep normal iOS browsers on WebKit, and Safari on iOS does not support Web MIDI. That means the named vulnerable feature path is likely absent in the majority of enterprise deployments.
• Exposure population is narrow: this is not a VPN, gateway, or SSO edge service; it is a mobile client app on individual handsets, with no meaningful external attack-surface census.
• Modern controls add more drag: Safe Browsing, MTD, managed link handling, and user-click requirements each shave off practical exploit volume before we even get to the memory-corruption step.
• Blast radius is per-device: even in the bad case, this is about compromising a handset session, not mass compromise of a server tier or identity plane.

Why not higher?

Because the path is stacked with real-world friction: user interaction, client-side only, and most importantly a likely non-existent WebMIDI surface on standard iOS browser-engine deployments. If the named feature is not exposed, the CRITICAL browser-exploit chain is mostly academic for enterprise prioritization.

Why not lower?

I am not calling this IGNORE because the vendor still shipped a fix for a memory-safety bug with potential sandbox escape impact, and Apple now has limited regional/entitlement-based paths for alternative browser engines. If you run beta channels, EU/Japan browser-engine experiments, or unmanaged mobile populations, that edge case deserves verification rather than dismissal.

1. Inventory Chrome iOS versions — Pull this from MDM/mobile app inventory and identify anything below 149.0.7827.53. For a LOW verdict there is no mitigation SLA; handle it in the next normal mobile-app hygiene cycle and document any exception populations.
2. Keep App Store auto-update enforcement on — For managed iPhones and iPads, use your normal MDM policy to keep Chrome updating automatically. That closes this issue without burning incident-response time; for LOW, treat it as backlog hygiene rather than an interrupt-driven change.
3. Review alternative-engine pilots — If your org has any regional browser-engine pilots, beta tracks, or special entitlements that could change iOS browser feature exposure, validate those separately. That is the one scenario where this CVE could move closer to the vendor's model.

Run this on an auditor workstation against an exported MDM/app inventory CSV, not on the iPhone itself. Invoke it as python3 check_chrome_ios_cve_2026_11165.py inventory.csv; it needs only read access to the CSV and no endpoint admin rights. Expected columns are flexible, but the script works best with device, app or bundle_id, and version.

#!/usr/bin/env python3
# check_chrome_ios_cve_2026_11165.py
# Purpose: assess Chrome on iOS inventory for CVE-2026-11165 exposure
# Usage: python3 check_chrome_ios_cve_2026_11165.py inventory.csv
# Exit codes:
#   0 = all matching Chrome iOS entries are PATCHED
#   1 = at least one matching Chrome iOS entry is VULNERABLE
#   2 = UNKNOWN (missing data, parse issues, or no matching rows)

import csv
import re
import sys
from pathlib import Path

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


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


def looks_like_chrome_ios(app, bundle):
    a = norm(app).lower()
    b = norm(bundle).lower()
    if b in CHROME_BUNDLES:
        return True
    if 'chrome' in a and ('ios' in a or 'iphone' in a or 'ipad' in a):
        return True
    if a == 'google chrome':
        return True
    return False


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


def cmp_ver(a, b):
    return (a > b) - (a < b)


def pick(row, *names):
    lower = {k.lower(): v for k, v in row.items()}
    for name in names:
        if name.lower() in lower:
            return lower[name.lower()]
    return ''


if len(sys.argv) != 2:
    print('UNKNOWN - usage: python3 check_chrome_ios_cve_2026_11165.py inventory.csv')
    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)

seen = 0
vuln = 0
unknown = 0
patched = 0

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

    for row in reader:
        device = norm(pick(row, 'device', 'device_name', 'hostname', 'serial', 'asset')) or 'UNKNOWN_DEVICE'
        app = pick(row, 'app', 'application', 'app_name', 'name')
        bundle = pick(row, 'bundle_id', 'bundle', 'package', 'identifier')
        version_raw = pick(row, 'version', 'app_version', 'installed_version')

        if not looks_like_chrome_ios(app, bundle):
            continue

        seen += 1
        ver = parse_version(version_raw)
        if ver is None:
            unknown += 1
            print(f'{device}: UNKNOWN - Chrome iOS version missing or unparsable ({version_raw!r})')
            continue

        if cmp_ver(ver, FIXED) < 0:
            vuln += 1
            print(f'{device}: VULNERABLE - Chrome iOS {version_raw} < 149.0.7827.53')
        else:
            patched += 1
            print(f'{device}: PATCHED - Chrome iOS {version_raw} >= 149.0.7827.53')

if seen == 0:
    print('UNKNOWN - no Chrome iOS rows matched; verify app/bundle naming in the CSV')
    sys.exit(2)

summary = f'SUMMARY matched={seen} vulnerable={vuln} patched={patched} unknown={unknown}'
print(summary)

if vuln > 0:
    sys.exit(1)
elif unknown > 0:
    sys.exit(2)
else:
    sys.exit(0)

Sources

1. VulDB entry for CVE-2026-11165
2. Chrome Stable for iOS 149 release note
3. Apple App Review Guidelines
4. Apple Web Browser Engine Entitlement
5. Can I use: Web MIDI API
6. MDN Web MIDI API reference
7. FIRST EPSS API
8. CISA Known Exploited Vulnerabilities Catalog