This is a trapdoor that only opens if the victim walks across the exact floor tiles
CVE-2026-10951 is a use-after-free in Chrome for iOS Autofill. A hostile page can apparently maneuver the browser into a bad object-lifetime state, but only on Chrome on iOS before 149.0.7827.53 and only if the victim is pushed through specific UI gestures tied to Autofill interaction.
Google's HIGH/8.8 label is fair if you score memory corruption in a browser in a vacuum, but it overshoots operational reality. This is not an unauthenticated server bug, not a drive-by no-click, not internet-scannable, and not backed by KEV, public exploit evidence, or a healthy EPSS signal; the required user choreography and iOS app constraints push this down into MEDIUM for enterprise patch triage.
4 steps from start to impact.
Land the lure in Chrome on iOS
- Victim uses Google Chrome on iPhone or iPad
- Installed version is earlier than
149.0.7827.53 - Victim can be induced to browse attacker-controlled content
- Only the iOS Chrome population is in scope, not desktop Chrome or Android
- Secure web gateways, DNS filtering, mail controls, and user behavior reduce lure success
- No mass internet discovery path exists because this is a client-side app flaw
Force the Autofill interaction path
- Victim interacts with fields that can invoke Autofill
- Victim performs the gesture sequence the bug depends on
- This is materially harder than ordinary
UI:Rbecause the advisory calls out *specific* gestures - Many users will abandon, mistap, or never invoke Autofill
- Managed users may not use Chrome Autofill at all
Trigger heap corruption in Autofill
- Precise vulnerable code path is reached
- Exploit can shape heap state well enough to get beyond a crash
- Modern memory mitigations, allocator behavior, ASLR, and iOS hardening increase exploit engineering cost
- No public PoC or weaponized exploit was located
- Google kept the underlying bug details restricted during rollout
Convert browser corruption into useful impact
- Reliable code execution from the heap bug
- A follow-on path if the attacker wants to break beyond app-level impact
- Chrome on iOS uses Apple's web stack and is constrained by iOS app architecture
- Single-process and app-sandbox realities limit blast radius compared with desktop browser exploitation
- No evidence of an in-the-wild full chain exists
The supporting signals.
| In-the-wild status | No public evidence of active exploitation found. I did not find KEV inclusion, vendor zero-day language, or public campaign reporting tied to this CVE. |
|---|---|
| Public PoC availability | No public PoC located. GitHub Advisory lists the bug as unreviewed and does not link exploit code; Chromium bug details remain restricted. |
| EPSS | 0.035% (11th percentile), which is a weak near-term exploitation signal for patch prioritization. |
| KEV status | Not KEV-listed as of the advisory data reviewed. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H — vendor scoring assumes high impact after successful exploitation, but the decisive real-world limiter is the required user gesture sequence. |
| Affected versions | Chrome on iOS earlier than 149.0.7827.53. |
| Fixed version | Upgrade to 149.0.7827.53 or later. Public Chrome iOS release posts show 149 rollouts on May 20 and May 27, 2026; the CVE record names .53 as the security fix level. |
| Exposure / scanning reality | No Shodan/Censys-style exposure story here. This is a client-side mobile app flaw, so external attack-surface scanners cannot enumerate it; your real inventory source is MDM/EMM app-version data. *That exposure conclusion is an inference from the product type and platform, not a direct vendor statement.* |
| Disclosure timeline | NVD received the CVE on 2026-06-04; GitHub Advisory published on 2026-06-05. |
| Reporter / origin | Reported by Google in the Chrome 149 security notes, with the Autofill issue tracked in Chromium issue 505191883. |
noisgate verdict.
The single biggest downshift factor is the attacker's need for a victim to perform specific Autofill UI gestures inside Chrome on iOS. That prerequisite sharply narrows both reachable population and exploit reliability, turning this from a scary browser-memory-corruption headline into a lower-throughput enterprise risk.
Why this verdict
- Vendor 8.8 starts too high for fleet triage because this is a client-side iOS browser bug, not a remotely reachable enterprise service
- Specific UI gestures are a real friction multiplier; this is more restrictive than generic
UI:Rand implies a brittle social-engineering sequence - Reachable population is narrower: only users on Chrome for iOS before
149.0.7827.53are exposed, and MDM-managed mobile fleets are usually a smaller patch domain than desktop browsers - There is no exploitation amplifier: no KEV listing, no public exploit, and EPSS is only
0.035%at the11th percentile - Blast radius is constrained by platform reality: Chrome on iOS uses Apple's web stack and runs within iOS app constraints, so a successful memory bug is less strategically valuable than the same class on desktop Chrome
Why not higher?
To earn HIGH in a 10,000-host environment, I want either active exploitation, broad no-click/one-click reach, or a large externally exposed population. This has none of those. The advisory itself says the attacker must convince the victim to perform specific gestures, which is exactly the kind of compounding friction that drags severity down.
Why not lower?
It is still a real memory corruption bug in a popular browser app, not a cosmetic crash. If a capable actor develops a stable chain, there is meaningful user-level impact potential, especially for targeted users who sync credentials or browse sensitive internal resources from managed iPhones.
What to do — in priority order.
- Pull exact version inventory from MDM — Use Intune, Jamf, Workspace ONE, or your mobile app inventory to identify devices running Chrome for iOS earlier than
149.0.7827.53. Because this is a MEDIUM verdict, there is no mitigation SLA — go straight to the 365-day remediation window, but do the inventory work now so the patch does not disappear into mobile backlog. - Prioritize high-risk user cohorts — Focus first on executives, admins, developers, IR staff, and users who handle external mail or untrusted links on iOS. There is no mitigation SLA for a MEDIUM here, but reducing the risky user subset early gives you the best risk reduction while mobile updates propagate.
- Reduce malicious-link delivery to mobile — Tighten mobile-safe-browsing, DNS filtering, mail rewriting, and attachment/link detonation policies for iPhone/iPad users. This does not replace patching, but it meaningfully cuts the first step in the chain while you work toward remediation within the MEDIUM 365-day window.
- Monitor Chrome iOS crash anomalies — If your mobile telemetry stack can surface app crash spikes, watch for unusual crash clusters tied to Chrome after suspicious link campaigns. This is useful for detection because exploit attempts against memory corruption often fail noisily before they become reliable.
- Traditional perimeter vulnerability scanning doesn't help because there is no server-side surface to probe.
- A WAF or reverse proxy won't save you; the trigger is in a client browser app, usually over normal HTTPS browsing.
- Desktop EDR assumptions do not transfer well to iOS; visibility and response depth are far weaker on mobile.
Crowdsourced verification payload.
Run this on an auditor workstation or CI runner, not on the iPhone itself. Export your MDM/EMM mobile app inventory to CSV, then run python3 check_chrome_ios_cve_2026_10951.py devices.csv; no admin rights are required, but the CSV must include at least a device identifier and an installed app version column.
#!/usr/bin/env python3
# check_chrome_ios_cve_2026_10951.py
#
# Purpose:
# Audit MDM/EMM CSV exports for Chrome on iOS versions vulnerable to CVE-2026-10951.
#
# Usage:
# python3 check_chrome_ios_cve_2026_10951.py devices.csv
#
# Expected CSV:
# Flexible column matching. The script looks for likely device/app/version columns.
# Best effort fields include:
# - device_name / device / hostname / serial / user
# - app_name / application / bundle_id / package
# - version / app_version / installed_version
# - platform / os / operating_system (optional, used to filter iOS/iPadOS rows)
#
# Exit codes:
# 0 = all matching Chrome iOS installs are PATCHED, or none found
# 1 = one or more VULNERABLE installs found
# 2 = UNKNOWN / parse failure / insufficient data
import csv
import sys
from pathlib import Path
FIXED = (149, 0, 7827, 53)
CHROME_NAMES = {
'google chrome', 'chrome', 'chrome ios', 'google chrome: fast & secure'
}
CHROME_BUNDLES = {
'com.google.chrome.ios', 'com.google.chrome'
}
IOS_MARKERS = {'ios', 'ipados', 'iphone', 'ipad'}
def norm(s):
return (s or '').strip().lower()
def parse_version(v):
v = (v or '').strip()
if not v:
return None
parts = []
for token in v.split('.'):
token = token.strip()
if not token.isdigit():
num = ''
for ch in token:
if ch.isdigit():
num += ch
else:
break
token = num
if token == '':
break
parts.append(int(token))
if not parts:
return None
while len(parts) < 4:
parts.append(0)
return tuple(parts[:4])
def cmp_ver(a, b):
return (a > b) - (a < b)
def pick(row, candidates):
lowered = {k.lower(): k for k in row.keys()}
for c in candidates:
if c in lowered:
return row.get(lowered[c], '')
return ''
def row_is_ios(row):
platform = norm(pick(row, ['platform', 'os', 'operating_system', 'device_os']))
if not platform:
return True # don't exclude if platform field absent
return any(marker in platform for marker in IOS_MARKERS)
def row_is_chrome(row):
app = norm(pick(row, ['app_name', 'application', 'app', 'name', 'package_name']))
bundle = norm(pick(row, ['bundle_id', 'bundle', 'package', 'identifier']))
return app in CHROME_NAMES or bundle in CHROME_BUNDLES or 'chrome' in app or bundle.startswith('com.google.chrome')
def device_label(row):
for field in ['device_name', 'device', 'hostname', 'serial', 'user', 'username', 'owner']:
value = pick(row, [field])
if value:
return value
return '<unknown-device>'
def main():
if len(sys.argv) != 2:
print('UNKNOWN - usage: python3 check_chrome_ios_cve_2026_10951.py devices.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)
vulnerable = []
patched = []
unknown = []
matched_any = False
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 row in reader:
if not row_is_ios(row):
continue
if not row_is_chrome(row):
continue
matched_any = True
version_raw = pick(row, ['version', 'app_version', 'installed_version', 'application_version'])
version = parse_version(version_raw)
label = device_label(row)
if version is None:
unknown.append((label, version_raw or '<blank>'))
continue
if cmp_ver(version, FIXED) < 0:
vulnerable.append((label, version_raw))
else:
patched.append((label, version_raw))
except Exception as e:
print(f'UNKNOWN - parse error: {e}')
sys.exit(2)
if not matched_any:
print('UNKNOWN - no Chrome on iOS rows matched; verify your CSV columns and app naming')
sys.exit(2)
for label, ver in vulnerable:
print(f'VULNERABLE,{label},{ver}')
for label, ver in patched:
print(f'PATCHED,{label},{ver}')
for label, ver in unknown:
print(f'UNKNOWN,{label},{ver}')
if vulnerable:
sys.exit(1)
if unknown and not patched:
sys.exit(2)
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
149.0.7827.53, then patch the high-risk user subset first and mop up the rest through your normal mobile-app update cadence. For this MEDIUM reassessment there is no noisgate mitigation SLA — go straight to the 365-day remediation window, but don't let that translate into indifference: mobile browser version drift is exactly how low-signal bugs stay exposed for months; target completion inside the noisgate remediation SLA of ≤365 days.Sources
- GitHub Advisory Database - GHSA-h7rf-vm92-f53j
- NVD - CVE-2026-10951
- Chrome Releases - Stable Channel Update for Desktop (Chrome 149 security notes)
- Chrome Releases - Chrome for iOS label archive
- Apple App Review Guidelines
- Chrome for Developers - Getting started with Chrome on iOS
- Chromium issue 505191883
- CISA Known Exploited Vulnerabilities Catalog
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.