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

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

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

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.

"Real bug, narrow path: this is a user-driven iOS client exploit, not a fleet-wide fire drill."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the lure in Chrome on iOS

The attacker needs a victim to open a crafted HTML page in Chrome on iOS, likely via phishing, chat, ad redirection, or a malicious site. The page itself is just delivery; there is no exposed service to scan or smash from the internet.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Network scanners will miss this entirely. Coverage is mostly indirect: phishing telemetry, DNS/SWG logs, mobile browsing telemetry, and MDM inventory for app version.
STEP 02

Force the Autofill interaction path

The crafted page then has to steer the victim into specific UI gestures that exercise the vulnerable Autofill path. This matters: the attacker does not just need a page render, they need the human to perform the right taps and selections in the right app UI state.
Conditions required:
  • Victim interacts with fields that can invoke Autofill
  • Victim performs the gesture sequence the bug depends on
Where this breaks in practice:
  • This is materially harder than ordinary UI:R because the advisory calls out *specific* gestures
  • Many users will abandon, mistap, or never invoke Autofill
  • Managed users may not use Chrome Autofill at all
Detection/coverage: Exploit kits are unlikely to be obvious here; detection is weak unless you collect browser crash analytics or mobile app telemetry.
STEP 03

Trigger heap corruption in Autofill

If the victim stays on the rails, the Autofill code hits a use-after-free and may corrupt heap state. At this stage many attempts will simply crash the app; turning a UAF into controlled execution on a modern iOS target is a different caliber of work than reproducing a crash.
Conditions required:
  • Precise vulnerable code path is reached
  • Exploit can shape heap state well enough to get beyond a crash
Where this breaks in practice:
  • 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
Detection/coverage: MDM and EMM tools may show app crash spikes after exploitation attempts, but signature-style detection is poor. Traditional vuln scanners do not validate the trigger path.
STEP 04

Convert browser corruption into useful impact

The optimistic attacker outcome is code execution or meaningful data access inside the Chrome iOS app context. For full device compromise or durable post-exploitation, they'd likely need an additional chain because Chrome on iOS is an iOS app subject to platform constraints rather than a full desktop-style browser stack.
Conditions required:
  • Reliable code execution from the heap bug
  • A follow-on path if the attacker wants to break beyond app-level impact
Where this breaks in practice:
  • 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
Detection/coverage: Post-impact visibility on iOS is limited; defenders mostly rely on MDM posture, crash analytics, and suspicious link-delivery telemetry rather than rich endpoint forensics.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo 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 availabilityNo public PoC located. GitHub Advisory lists the bug as unreviewed and does not link exploit code; Chromium bug details remain restricted.
EPSS0.035% (11th percentile), which is a weak near-term exploitation signal for patch prioritization.
KEV statusNot KEV-listed as of the advisory data reviewed.
CVSS vectorCVSS: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 versionsChrome on iOS earlier than 149.0.7827.53.
Fixed versionUpgrade 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 realityNo 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 timelineNVD received the CVE on 2026-06-04; GitHub Advisory published on 2026-06-05.
Reporter / originReported by Google in the Chrome 149 security notes, with the Autofill issue tracked in Chromium issue 505191883.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (5.6/10)

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.

HIGH No active exploitation / no KEV / weak EPSS signal
MEDIUM Practical exploitability and blast radius on managed iOS fleets

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:R and implies a brittle social-engineering sequence
  • Reachable population is narrower: only users on Chrome for iOS before 149.0.7827.53 are 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 the 11th 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.

05 · Compensating Control

What to do — in priority order.

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

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.

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

If you remember one thing.

TL;DR
Monday morning, pull MDM inventory for Chrome on iOS and sort devices below 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

  1. GitHub Advisory Database - GHSA-h7rf-vm92-f53j
  2. NVD - CVE-2026-10951
  3. Chrome Releases - Stable Channel Update for Desktop (Chrome 149 security notes)
  4. Chrome Releases - Chrome for iOS label archive
  5. Apple App Review Guidelines
  6. Chrome for Developers - Getting started with Chrome on iOS
  7. Chromium issue 505191883
  8. CISA Known Exploited Vulnerabilities Catalog
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.