This is the second lock on the door, not the open window
CVE-2026-10915 is a CWE-416 use-after-free in Chrome for iOS Core, affecting versions prior to 149.0.7827.53 and fixed in 149.0.7827.53. The bug is not described as a one-click browser-to-device compromise by itself; the stated prerequisite is that the attacker has already compromised the renderer process and then uses a crafted HTML page to push farther.
The vendor's HIGH 8.3 overstates operational urgency for enterprise patch triage because that score reflects the technical impact of a successful chain, not the real-world friction. On iOS, Chrome is layered on top of Apple's WKWebView/WebKit model, so this CVE is a post-renderer step in a multi-bug chain; that sharply narrows reachable population, raises attacker cost, and limits stand-alone value unless paired with a separate renderer exploit and likely a further iOS escape.
4 steps from start to impact.
Land a renderer/WebContent foothold first
- Target is running Chrome on iOS below
149.0.7827.53 - User opens attacker-controlled content
- Attacker has a working renderer/WebContent compromise primitive first
- This CVE is not initial access; it is post-renderer-compromise
- No public PoC was found for this CVE
- Reliable renderer exploitation on current iOS builds is non-trivial and usually burned privately
Trigger the Core use-after-free
Core object is reused. The weaponized tool is effectively a custom crafted HTML/JS page plus a private exploit primitive; no public exploit framework or repo was located for this CVE.- Attacker can drive renderer-originated messages or state transitions into the vulnerable path
- Precise target build behavior matches the exploit's assumptions
- Use-after-free exploitation usually needs version-specific heap grooming
- Small build changes often break reliability
- The attacker still has to bridge from a content process condition to a browser-side win
Escape the renderer boundary
- Successful exploitation of the UAF
- A useful post-escape primitive in the browser/app context
- Chrome on iOS is constrained by Apple's browser engine model
- Escaping into the app/browser context is still not the same as full device compromise
- Enterprise data access often remains gated by app sandboxing, MDM policy, and per-app auth
Chain again for full device impact
- Attacker wants impact beyond browser/app context
- A second post-browser iOS exploit is available
- Another exploit is usually required for meaningful device takeover
- That sharply limits commodity attacker use
- No exploitation evidence or KEV listing was found
The supporting signals.
| In-the-wild status | No public evidence of active exploitation found; not present in CISA KEV. |
|---|---|
| Public PoC availability | No public exploit repo or researcher PoC located for CVE-2026-10915; assume private-chain only unless new intel appears. |
| EPSS | 0.00068 (0.068%) from the prompt — effectively near the floor of exploit-likelihood scoring; percentile was not supplied in the prompt. |
| KEV status | No as of 2026-06-05; no KEV release date or due date applies. |
| CVSS vector | CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H — the important real-world signal is AC:H + UI:R, and the description adds an even bigger hidden gate: prior renderer compromise. |
| Affected versions | Chrome on iOS before 149.0.7827.53. |
| Fixed version | Patched in 149.0.7827.53 for iOS. |
| Scanning / exposure data | Shodan/Censys/FOFA-style exposure data is basically not applicable. This is a client app on managed iPhones, not an internet-listening service. |
| Disclosure date | 2026-06-04. |
| Reporter / advisory source | Public attribution was not found in the available sources; advisory context points to Google/Chrome CNA disclosure. |
noisgate verdict.
The decisive downgrade driver is the prerequisite that the attacker must already have compromised the renderer process before this bug becomes useful. That makes CVE-2026-10915 a post-initial-compromise chain component with a materially narrower exposed population and higher attacker cost than the vendor's stand-alone HIGH label suggests.
Why this verdict
- Renderer compromise required: this is not unauthenticated remote initial access; it assumes the attacker has already cleared the hardest step in the chain.
- iOS platform friction: Chrome on iOS is built on Apple's
WKWebView/WebKit model, which narrows how broadly a Chrome-specific sandbox-escape step can be weaponized compared with desktop Chrome. - Low attacker signal: EPSS is
0.00068, there is no KEV listing, and no public PoC or campaign reporting was found.
Why not higher?
A higher rating would fit a bug that turns a browser visit directly into code execution or device compromise at scale. This one does not: it needs a prior renderer foothold, likely a private exploit chain, and probably another iOS step afterward for full-device impact.
Why not lower?
This is still a memory-corruption flaw in a massively deployed browser and it sits in a part of the chain attackers care about. If you run managed iOS fleets, especially high-risk user groups, a browser sandbox-escape component should not be dismissed as mere backlog noise.
What to do — in priority order.
- Force Chrome iOS auto-update compliance — Use MDM/App Store controls to make sure enrolled iPhones move to
149.0.7827.53or later. For a MEDIUM verdict there is no mitigation SLA; use this as straight remediation work inside the 365-day remediation window. - Prioritize high-risk user cohorts first — Move executives, admins, journalists, and other phishing-prone or targeted users to the patched build first because they are the most plausible recipients of private mobile exploit chains. Again, no mitigation SLA applies at this severity; this is risk-reduction while you work the remediation queue.
- Watch mobile browser crash telemetry — Pull MDM, mobile threat defense, and app analytics for repeated Chrome/WebContent crashes or abnormal browser instability on iOS. That will not prove exploitation, but it gives you the best available signal for a client-side memory bug where network scanners see nothing.
- Reduce risky browsing paths on managed devices — Apply DNS/web filtering, Safe Browsing enforcement, and high-risk category blocks on managed iPhones to cut the chance of users ever reaching a chain-delivery page. For MEDIUM, this is optional hardening, not a timed mitigation obligation.
- Perimeter vulnerability scanning doesn't help much because there is no internet-facing service to probe.
- MFA does not block exploitation of a browser memory bug; it only limits what stolen sessions can do afterward.
- WAF rules are largely irrelevant because the vulnerable surface is a client browser/app, not your server-side web stack.
Crowdsourced verification payload.
Run this on an auditor workstation against your MDM export or use it for one-off version checks. Example: python3 check_cve_2026_10915.py --version 149.0.7827.26 or python3 check_cve_2026_10915.py --csv ios_apps.csv --column app_version; no device privileges are required.
#!/usr/bin/env python3
# check_cve_2026_10915.py
# Determine exposure to CVE-2026-10915 for Chrome on iOS.
# Outputs: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=usage/error
import argparse
import csv
import re
import sys
from typing import Optional, Tuple
FIXED = (149, 0, 7827, 53)
def parse_version(v: str) -> Optional[Tuple[int, int, int, int]]:
if v is None:
return None
m = re.match(r'^\s*(\d+)\.(\d+)\.(\d+)\.(\d+)\s*$', v)
if not m:
return None
return tuple(int(x) for x in m.groups())
def classify(v: str) -> str:
parsed = parse_version(v)
if not parsed:
return 'UNKNOWN'
return 'PATCHED' if parsed >= FIXED else 'VULNERABLE'
def main() -> int:
ap = argparse.ArgumentParser(description='Check Chrome on iOS versions for CVE-2026-10915')
ap.add_argument('--version', help='Single Chrome iOS version, e.g. 149.0.7827.26')
ap.add_argument('--csv', help='CSV export from MDM/app inventory')
ap.add_argument('--column', default='app_version', help='CSV column containing version strings (default: app_version)')
ap.add_argument('--name-column', default='device', help='CSV column for device identifier (default: device)')
args = ap.parse_args()
if bool(args.version) == bool(args.csv):
print('UNKNOWN: provide exactly one of --version or --csv')
return 3
if args.version:
result = classify(args.version)
print(result)
return {'PATCHED': 0, 'VULNERABLE': 1, 'UNKNOWN': 2}[result]
vulnerable = 0
patched = 0
unknown = 0
try:
with open(args.csv, newline='', encoding='utf-8-sig') as fh:
reader = csv.DictReader(fh)
if args.column not in (reader.fieldnames or []):
print(f"UNKNOWN: column '{args.column}' not found in CSV")
return 3
for row in reader:
version = (row.get(args.column) or '').strip()
device = (row.get(args.name_column) or 'UNKNOWN_DEVICE').strip()
result = classify(version)
print(f'{device},{version},{result}')
if result == 'VULNERABLE':
vulnerable += 1
elif result == 'PATCHED':
patched += 1
else:
unknown += 1
except FileNotFoundError:
print('UNKNOWN: CSV file not found')
return 3
except Exception as e:
print(f'UNKNOWN: failed to process CSV: {e}')
return 3
if vulnerable > 0:
print(f'SUMMARY,VULNERABLE,vulnerable={vulnerable},patched={patched},unknown={unknown}')
return 1
if patched > 0 and unknown == 0:
print(f'SUMMARY,PATCHED,vulnerable={vulnerable},patched={patched},unknown={unknown}')
return 0
print(f'SUMMARY,UNKNOWN,vulnerable={vulnerable},patched={patched},unknown={unknown}')
return 2
if __name__ == '__main__':
sys.exit(main())
If you remember one thing.
149.0.7827.53, and roll them into normal mobile-app remediation rather than emergency response. For this MEDIUM reassessment there is noisgate mitigation SLA — go straight to the 365-day remediation window; use web filtering and high-risk-user prioritization as optional exposure reduction, then complete the actual app update under the noisgate remediation SLA of ≤ 365 days.Sources
- Chrome Releases 2026 index
- Chrome Stable 149 for iOS
- Early Stable 149.0.7827.53/.54 desktop release context
- Chromium iOS web layer README
- Chromium Blog: Chrome on iOS with WKWebView out-of-process rendering
- Apple BrowserEngineKit / WKWebView isolation context
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS documentation
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.