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

Use after free in Autofill in Google Chrome prior to 149

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

This is not a burglar kicking in the front door, it's the second lock failing after the intruder is already in the hallway

CVE-2026-11002 is a use-after-free in Chrome Autofill that can turn a *pre-existing renderer compromise* into a potential sandbox escape. The authoritative CVE text matters here: the attacker must already have compromised the renderer process, then use a crafted HTML page to drive the vulnerable Autofill path. NVD lists affected Chrome builds as versions before 149.0.7827.53; Google's early stable release notes show the fix shipping in 149.0.7827.53/.54 for desktop.

The 9.6/CRITICAL CVSS framing overstates operational risk for enterprise patch triage because it scores impact after the chain is complete, not the friction required to get there. Chromium's own severity label is *Medium*, and that directionally matches reality better: this is a valuable defense-in-depth break for exploit chains, but it is not a standalone web-to-host compromise and there is no current KEV listing, no public in-the-wild evidence, and an extremely low EPSS in the intel you supplied.

"Critical on paper, medium in practice: this only pays off after the attacker already owns the renderer"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land code execution in the renderer first

The attacker needs a separate renderer-code-execution bug before this CVE becomes relevant at all. In practice that usually means a distinct V8, Blink, media, or parser exploit delivered through a malicious page, ad slot, or embedded content. This CVE is the *second-stage privilege boundary bypass*, not the initial foothold.
Conditions required:
  • Victim browses attacker-controlled content
  • A separate working renderer exploit exists for the victim's exact Chrome build
  • The attacker can get reliable code execution inside the sandboxed renderer
Where this breaks in practice:
  • This CVE does not provide initial code execution by itself
  • Exploit reliability is version- and platform-sensitive
  • User interaction is still required because the victim must load attacker content
Detection/coverage: Standard vuln scanners usually cannot validate this step. Detection is mostly indirect: web proxy logs, Safe Browsing blocks, crash telemetry, and exploit-chain artifacts.
STEP 02

Drive the Autofill use-after-free

Once inside the renderer, the attacker uses crafted HTML/DOM behavior to reach the vulnerable Autofill lifecycle and trigger a stale object access. The goal is not just a crash, but a controlled memory primitive stable enough to cross the sandbox boundary logic.
Conditions required:
  • Target is running a vulnerable Chrome version before 149.0.7827.53
  • The Autofill code path is reachable in the victim session
  • Heap state can be groomed well enough for exploitation
Where this breaks in practice:
  • Use-after-free bugs often crash more than they exploit
  • Heap grooming reliability drops across channels, architectures, and minor builds
  • Feature state and browsing context can affect reachability
Detection/coverage: Limited direct coverage. Browser crash spikes, renderer terminations, and unusual child-process churn may be the only visible signals.
STEP 03

Turn renderer control into sandbox escape

The attacker then abuses the Autofill bug to break Chrome's renderer-to-privileged-process security boundary. That is the real value of this CVE: upgrading a sandboxed browser foothold into broader access under the user's context.
Conditions required:
  • Successful exploitation of the Autofill memory corruption
  • A path from compromised renderer state to privileged process impact
  • Platform/browser mitigations do not break the chain
Where this breaks in practice:
  • Chrome's sandbox, Site Isolation, and process mitigations exist specifically to make this hard
  • Modern Windows/macOS builds reduce exploit reliability compared with older platforms
  • A sandbox escape still needs a practical post-escape objective
Detection/coverage: Enterprise EDR may catch abnormal browser child-process behavior or post-escape payload execution, but not the escape itself with high fidelity.
STEP 04

Operate with user-context access

If the chain works, the attacker moves from a caged renderer to access consistent with the browser or user context, enabling data theft, credential access, persistence attempts, or staging of another local privilege escalation. The blast radius is real, but only after a sophisticated multi-bug chain succeeds.
Conditions required:
  • Successful sandbox escape
  • Valuable local/browser data present
  • No downstream control blocks post-exploitation activity
Where this breaks in practice:
  • Post-escape access is generally still user-level, not kernel/admin by default
  • EDR, app control, and identity protections can still contain follow-on actions
  • The attacker had to clear multiple high-skill gates before reaching this point
Detection/coverage: EDR and browser telemetry are most useful here: suspicious file access from browser processes, credential store touches, unusual process trees, or persistence attempts.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence of active exploitation found as of 2026-06-05. Chromium's public security docs distinguish fixed bugs with *in-the-wild* evidence, and this CVE does not carry that signal in the sources reviewed.
Public PoC availabilityNo credible public PoC or GitHub exploit for CVE-2026-11002 surfaced in targeted searches. The referenced Chromium issue is access-restricted, which is normal for fresh Chrome security bugs.
EPSS0.00035 (~0.035%) from the intel you supplied, which is *very low* and consistent with a hard-to-operationalize second-stage browser bug.
KEV statusNot KEV-listed. A direct search for this CVE on CISA sources returned no result; that supports absence from the Known Exploited Vulnerabilities Catalog.
Severity split that mattersNVD shows 9.6 CRITICAL with CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H, but the CVE description itself states Chromium security severity: Medium. For defenders, that split is the whole story.
Affected versionsNVD's affected range is Chrome versions before 149.0.7827.53. Google's early stable notes confirm 149.0.7827.53/.54 as the desktop fix train.
Fixed versionsDesktop early stable shipped in 149.0.7827.53/.54 for Windows/Mac. Treat 149.0.7827.53+ as the minimum safe baseline for fleet validation.
Exposure realityThis is a client-side browser flaw, not a remotely enumerable service. Shodan/Censys/FOFA/GreyNoise are weak prioritization tools here because exposure lives in user browsing activity and patch lag, not listening sockets.
Disclosure date2026-06-04 via the Chrome CNA / NVD publication path.
Reporter / originThe CVE record source is Chrome. The referenced issue is 494740162, but public details are restricted at time of review.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (6.4/10)

The decisive factor is the prerequisite chain: an attacker must already achieve renderer compromise before this bug becomes useful. That makes CVE-2026-11002 a defense-in-depth failure with real chain value, but not a standalone internet-scale remote compromise deserving top-of-queue emergency treatment.

HIGH Affected version floor and fixed version identification
MEDIUM Reassessed severity versus NVD's `9.6` baseline
HIGH No current public evidence of KEV listing or active exploitation

Why this verdict

  • Second-stage only: the CVE text explicitly requires a *compromised renderer process*. That means the attacker position is not unauthenticated remote in one shot; it implies a prior exploit stage already succeeded, which is a major downward pressure from the 9.6 paper score.
  • Reachable population is broad, but directly exploitable population is narrow: Chrome is everywhere, but only the subset on vulnerable builds *and* exposed to a separate working renderer exploit chain can be hit. That compounding prerequisite knocks this out of the true emergency bucket.
  • Modern browser defenses are doing work here: Site Isolation, sandboxing, OS mitigations, and EDR don't make it harmless, but they do add real friction to reliable exploitation. This is exactly the class of bug where exploit developers care a lot more than commodity threat actors.
  • No external urgency signal: no KEV, no public PoC, and the supplied EPSS is extremely low. When the ecosystem is quiet on a browser sandbox escape, defenders should resist treating the CVSS number as a fire alarm.
  • Why it still lands above LOW: if you already lose the renderer, a sandbox escape in a massively deployed browser is still a meaningful privilege boundary break. On 10,000 endpoints, you patch this because exploit chains exist, not because this CVE alone is likely to burn you tomorrow.

Why not higher?

A higher rating would require an amplifier that is missing here: active exploitation, public weaponization, or a chain that does not require prior renderer compromise. None of those are present in the reviewed sources. The prerequisite of already owning the renderer is not a minor caveat; it is the central risk-reducing fact.

Why not lower?

A lower rating would ignore that this is still a sandbox escape in the most exposed client application most enterprises run. Attackers building high-end browser chains absolutely care about bugs like this because they turn a renderer foothold into real host impact. That keeps it out of backlog-hygiene territory.

05 · Compensating Control

What to do — in priority order.

  1. Enforce browser auto-update compliance — Use Chrome enterprise policy and your endpoint management stack to verify that unmanaged or pinned builds are not stranded below 149.0.7827.53. For a MEDIUM noisgate verdict there is no mitigation SLA; apply this as normal hygiene while you drive remediation through standard browser maintenance.
  2. Hunt for version laggards — Query EDR, asset inventory, or software metering for Chrome versions <149.0.7827.53 and focus on VDI pools, kiosk images, golden images, and machines with disabled auto-update. These are the places browser patch drift survives longest and quietly expands exploit-chain exposure.
  3. Reduce unmanaged browsing paths — Block or flag non-corporate Chrome installs, portable browsers, and local admin exceptions that bypass your browser update channel. This matters because client-side browser exposure is primarily a *patch-lag* problem, not an open-port problem.
  4. Keep exploit-chain controls healthy — Maintain Safe Browsing, web filtering, ad/malvertising controls, and EDR browser telemetry because they attack the *first-stage renderer compromise* this CVE depends on. They do not fix the bug, but they lower the odds that an attacker ever gets to use it.
What doesn't work
  • Perimeter vulnerability scanning doesn't help much here because Chrome clients are not internet-enumerable services.
  • Network segmentation is largely irrelevant once the exploit is delivered through normal web browsing traffic to the endpoint.
  • Relying on EDR alone is weak; EDR may catch post-escape behavior, but it usually won't reliably stop the browser sandbox escape itself.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or via your fleet management tool with standard user rights; admin is not required if Chrome is installed in normal locations. Save as check_cve_2026_11002.py and run python3 check_cve_2026_11002.py on macOS/Linux or py check_cve_2026_11002.py on Windows. It will auto-discover common Chrome install paths and print VULNERABLE, PATCHED, or UNKNOWN.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_cve_2026_11002.py
# Detects whether local Google Chrome is below 149.0.7827.53
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

import os
import platform
import re
import shutil
import subprocess
import sys
from pathlib import Path

FIXED = (149, 0, 7827, 53)


def parse_version(text):
    m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', text)
    if not m:
        return None
    return tuple(int(x) for x in m.groups())


def version_to_str(v):
    return '.'.join(str(x) for x in v)


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


def run_cmd(cmd):
    try:
        p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=10)
        out = (p.stdout or '') + '\n' + (p.stderr or '')
        return p.returncode, out.strip()
    except Exception:
        return None, ''


def candidate_paths():
    system = platform.system().lower()
    paths = []

    if system == 'windows':
        envs = [
            os.environ.get('ProgramFiles'),
            os.environ.get('ProgramFiles(x86)'),
            os.environ.get('LocalAppData'),
        ]
        suffixes = [
            r'Google\Chrome\Application\chrome.exe',
            r'Chromium\Application\chrome.exe',
        ]
        for base in envs:
            if not base:
                continue
            for suf in suffixes:
                paths.append(str(Path(base) / Path(suf)))
        which = shutil.which('chrome') or shutil.which('chrome.exe') or shutil.which('google-chrome')
        if which:
            paths.append(which)

    elif system == 'darwin':
        paths.extend([
            '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
            str(Path.home() / 'Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
            '/Applications/Chromium.app/Contents/MacOS/Chromium',
        ])
        which = shutil.which('google-chrome') or shutil.which('chrome') or shutil.which('chromium')
        if which:
            paths.append(which)

    else:
        paths.extend([
            '/usr/bin/google-chrome',
            '/usr/bin/google-chrome-stable',
            '/opt/google/chrome/chrome',
            '/snap/bin/chromium',
            '/usr/bin/chromium',
            '/usr/bin/chromium-browser',
        ])
        for name in ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser', 'chrome']:
            which = shutil.which(name)
            if which:
                paths.append(which)

    # de-duplicate while preserving order
    seen = set()
    ordered = []
    for p in paths:
        if p and p not in seen:
            seen.add(p)
            ordered.append(p)
    return ordered


def get_version_from_binary(path):
    rc, out = run_cmd([path, '--version'])
    if rc is None:
        return None
    return parse_version(out)


def main():
    found = []
    for path in candidate_paths():
        if Path(path).exists() or shutil.which(path):
            v = get_version_from_binary(path)
            if v:
                found.append((path, v))

    if not found:
        print('UNKNOWN: Google Chrome/Chromium binary not found in common locations')
        sys.exit(2)

    # Prefer Google Chrome if present; otherwise use first discovered browser binary
    chosen = None
    for path, v in found:
        low = path.lower()
        if 'google' in low and 'chrome' in low:
            chosen = (path, v)
            break
    if not chosen:
        chosen = found[0]

    path, version = chosen
    if compare_versions(version, FIXED) < 0:
        print(f'VULNERABLE: {path} version {version_to_str(version)} is below fixed version {version_to_str(FIXED)}')
        sys.exit(1)
    else:
        print(f'PATCHED: {path} version {version_to_str(version)} is at or above fixed version {version_to_str(FIXED)}')
        sys.exit(0)


if __name__ == '__main__':
    main()
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: treat this as a browser fleet hygiene issue, not an out-of-band enterprise incident. Under the noisgate mitigation SLA, there is no mitigation SLA — go straight to the 365-day remediation window for a MEDIUM verdict; under the noisgate remediation SLA, make sure every managed endpoint moves to 149.0.7827.53+ within 365 days, but in practice you should validate Chrome auto-update health and clean up pinned/stranded builds this month so a second-stage sandbox escape does not remain available to future exploit chains.

Sources

  1. NVD CVE-2026-11002
  2. Chrome Releases - Early Stable Update for Desktop (149.0.7827.53/.54)
  3. Chromium severity guidelines
  4. Chromium Site Isolation overview
  5. Chrome sandbox diagnostics for Windows
  6. CISA Known Exploited Vulnerabilities Catalog
  7. FIRST EPSS data and statistics
  8. Chromium issue 494740162
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.