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

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

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

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.

"This is a chain component, not a stand-alone fire: renderer compromise is the real gate."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land a renderer/WebContent foothold first

The attacker needs a separate memory-corruption or logic bug to get code execution or equivalent control in the iOS web rendering process before CVE-2026-10915 matters. In practice this means a private exploit chain or a second CVE against the WebKit/WKWebView content process, delivered by a crafted page or content stream.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Conventional vuln scanners will flag version exposure, but they cannot validate exploitability of the required pre-chain. Web filtering, mobile threat defense, and crash telemetry are better signals than network scanners here.
STEP 02

Trigger the Core use-after-free

With renderer control, the attacker shapes object lifetime and browser-process interactions until the freed 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.
Conditions required:
  • Attacker can drive renderer-originated messages or state transitions into the vulnerable path
  • Precise target build behavior matches the exploit's assumptions
Where this breaks in practice:
  • 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
Detection/coverage: Version-only detection is straightforward through MDM/app inventory. Runtime detection is weak unless you capture app crash data, repeated WebContent process terminations, or mobile EDR anomalies.
STEP 03

Escape the renderer boundary

If exploitation succeeds, the attacker moves from the renderer/WebContent context into a less-restricted browser context. On desktop Chrome this class can materially matter for sandbox escape; on iOS the security value is still real, but the platform and app sandboxing model reduce the blast radius compared with a full workstation browser escape.
Conditions required:
  • Successful exploitation of the UAF
  • A useful post-escape primitive in the browser/app context
Where this breaks in practice:
  • 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
Detection/coverage: There is no meaningful internet-exposure scan for this step. Detection is mostly indirect: suspicious browser crashes, anomalous token use after browsing, or mobile telemetry showing browser process instability.
STEP 04

Chain again for full device impact

To turn this into a full iPhone compromise, the attacker typically still needs a further iOS privilege escalation or another sandbox break. That means CVE-2026-10915 is best understood as a chain-enabler, not the whole intrusion.
Conditions required:
  • Attacker wants impact beyond browser/app context
  • A second post-browser iOS exploit is available
Where this breaks in practice:
  • Another exploit is usually required for meaningful device takeover
  • That sharply limits commodity attacker use
  • No exploitation evidence or KEV listing was found
Detection/coverage: Mobile EDR/MTD, jailbreak detection, and unusual process or entitlement behavior are more relevant here than browser scanners.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence of active exploitation found; not present in CISA KEV.
Public PoC availabilityNo public exploit repo or researcher PoC located for CVE-2026-10915; assume private-chain only unless new intel appears.
EPSS0.00068 (0.068%) from the prompt — effectively near the floor of exploit-likelihood scoring; percentile was not supplied in the prompt.
KEV statusNo as of 2026-06-05; no KEV release date or due date applies.
CVSS vectorCVSS: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 versionsChrome on iOS before 149.0.7827.53.
Fixed versionPatched in 149.0.7827.53 for iOS.
Scanning / exposure dataShodan/Censys/FOFA-style exposure data is basically not applicable. This is a client app on managed iPhones, not an internet-listening service.
Disclosure date2026-06-04.
Reporter / advisory sourcePublic attribution was not found in the available sources; advisory context points to Google/Chrome CNA disclosure.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (5.8/10)

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.

HIGH Exploit preconditions materially reduce real-world reach
MEDIUM No public exploitation or PoC observed at current disclosure stage

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.

05 · Compensating Control

What to do — in priority order.

  1. Force Chrome iOS auto-update compliance — Use MDM/App Store controls to make sure enrolled iPhones move to 149.0.7827.53 or later. For a MEDIUM verdict there is no mitigation SLA; use this as straight remediation work inside the 365-day remediation window.
  2. 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.
  3. 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.
  4. 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.
What doesn't work
  • 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.
06 · Verification

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.

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

If you remember one thing.

TL;DR
Monday morning: pull your iOS app inventory, identify Chrome versions below 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

  1. Chrome Releases 2026 index
  2. Chrome Stable 149 for iOS
  3. Early Stable 149.0.7827.53/.54 desktop release context
  4. Chromium iOS web layer README
  5. Chromium Blog: Chrome on iOS with WKWebView out-of-process rendering
  6. Apple BrowserEngineKit / WKWebView isolation context
  7. CISA Known Exploited Vulnerabilities Catalog
  8. FIRST EPSS 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.