CVE-2026-110922 · Google Chrome Prerender Use-After-Free Renderer Code Execution

01 · The Real Story

Someone left a loaded mousetrap inside a locked safe — dangerous, but the safe door is still shut

CVE-2026-110922 is a use-after-free in Chrome's Prerender engine — the subsystem that speculatively loads pages before you click a link. A dangling pointer during prerender teardown lets an attacker who controls a crafted HTML page hijack the freed memory and achieve arbitrary code execution. The critical detail: execution lands inside Chrome's renderer sandbox, not on the host. Affected: every Chrome build prior to 155.0.8059.84 on Windows, macOS, and Linux. The Chromium project released the fix on October 15, 2026, bundled with nine other fixes in the same stable-channel push. Reporter: Xinyang Ge of Anthropic (disclosed 2026-10-02, 13-day patch cycle).

The Chromium security team stamped this Critical by their own severity taxonomy (renderer RCE = Critical), yet the CVSS vector lands at 8.8 / HIGH because S:U correctly scopes impact to the vulnerable component — the sandboxed renderer process. Both labels are *technically* right; neither tells the full story. The renderer sandbox is one of the hardest boundaries in any shipping browser: without a second, independent sandbox-escape bug, the attacker cannot touch the OS, cannot persist, cannot move laterally, and cannot escalate beyond reading or manipulating data already visible to the renderer (cookies, session tokens, page DOM for the affected site). Meanwhile, Chrome's auto-update pipeline will have quietly patched the vast majority of consumer and enterprise-managed installs within 48–72 hours of release. In practice, this CVE matters most to organizations with frozen or manually-managed Chrome versions — and as a chain starter if paired with a future sandbox-escape zero-day.

"Sandboxed renderer RCE in Chrome Prerender — real but contained. Auto-update is your best friend here."

02 · The Attack Path

5 steps from start to impact.

STEP 01

Craft malicious prerender payload

The attacker builds an HTML page (or set of pages) that triggers the use-after-free during Chrome's speculative prerender lifecycle. The payload uses heap spraying or PartitionAlloc bucket grooming to reclaim the freed object with attacker-controlled data. This is a non-trivial step: Chrome ships with MiraclePtr (BackupRefPtr) across all processes as of Q3 2026, which quarantines freed allocations if a dangling raw_ptr<T> still exists. The reporter likely found a code path where the dangling pointer is not wrapped in raw_ptr, or where the object's PartitionAlloc bucket is not covered. No public PoC exists.

Conditions required:

Deep knowledge of Chrome Prerender internals and PartitionAlloc heap layout
Ability to bypass or avoid MiraclePtr quarantine for the targeted object

Where this breaks in practice:

MiraclePtr now enforced on all processes/platforms — significantly narrows exploitable UAF surface
Chrome's ASLR + CFI + V8 sandbox make reliable exploitation hard without months of research
No public PoC or exploit code — only the reporter and Google have details

STEP 02

Deliver trigger page to victim

The attacker needs the victim's browser to initiate a prerender of the malicious page. This can happen via Speculation Rules (<script type='speculationrules'>) or <link rel='prerender'> on a page the victim visits. Delivery vectors: malvertising injection on a legitimate ad network, compromised legitimate site (watering hole), or spear-phishing link. The prerender fires without the user clicking the malicious link — visiting the trigger page is sufficient.

Conditions required:

Victim must visit a page containing the attacker's speculation rules or prerender hint
Browser must have Prerender / Speculation Rules enabled (default on)

Where this breaks in practice:

Safe Browsing and URL-reputation services can block known malicious URLs
Enterprise web proxies and SWGs inspect URLs before the browser sees them
Malvertising requires buying or compromising ad inventory — adds cost and detection surface

Detection/coverage: Google Safe Browsing flags known malicious URLs. Enterprise SWGs (Zscaler, Netskope, Palo Prisma) log and can block speculative navigation targets.

STEP 03

UAF triggers during prerender lifecycle

Chrome prerenders the attacker's page in a sandboxed renderer process. During navigation, teardown, or compositor handoff, the dangling pointer is dereferenced. The attacker's heap spray has reclaimed the freed slot with a crafted object whose vtable or function pointer redirects execution.

Conditions required:

Prerender must complete enough of the page lifecycle to hit the vulnerable code path
Heap layout must align — not guaranteed on first attempt; may need multiple page loads

Where this breaks in practice:

PartitionAlloc slot randomization and MiraclePtr quarantine reduce reliability
Chrome's renderer process has a short lifetime — crash-and-restart limits retry windows

Detection/coverage: Chrome crash reports (chrome://crashes) will show renderer OOM or SIGSEGV patterns if exploitation fails. CrowdStrike Falcon, SentinelOne, and Microsoft Defender for Endpoint can flag anomalous renderer crashes.

STEP 04

Arbitrary code execution inside sandbox

The attacker now has code execution within the renderer sandbox. This grants read/write access to the renderer process's memory: DOM content, JavaScript variables, cookies and session tokens for sites loaded in the same process, form data including passwords pre-autofill. The attacker can exfiltrate this data to a C2 server over the renderer's existing network socket (allowed by sandbox policy). However, the sandbox blocks: file system access, OS API calls, process creation, registry/kernel interaction, and cross-process IPC beyond Mojo to the browser process.

Conditions required:

Steps 1–3 succeed reliably

Where this breaks in practice:

Sandbox boundary prevents host-level compromise
Site Isolation means cross-origin data requires a separate renderer exploit
No persistence — killing the tab kills the attacker's code

Detection/coverage: Network-level detection of C2 beaconing from renderer (unusual outbound connections from chrome renderer to unknown IPs). Browser telemetry via Chrome Enterprise Reporting can surface anomalous renderer behavior.

STEP 05

(Hypothetical) Chain with sandbox escape for full compromise

To break out of the sandbox, the attacker needs a second independent vulnerability — typically a Mojo IPC bug, GPU process escape, or kernel exploit. No such chain has been demonstrated for this CVE. Without this step, the attack terminates at renderer-level access. Historically, full Chrome exploitation chains (renderer RCE + sandbox escape) are worth $250K–$500K on the exploit market and are almost exclusively the domain of nation-state actors or top-tier exploit brokers.

Conditions required:

A second zero-day sandbox escape vulnerability
Significant additional research investment

Where this breaks in practice:

Chrome's multi-layer sandbox (seccomp-bpf on Linux, seatbelt on macOS, restricted tokens on Windows) is one of the hardest targets in software
Full Chrome chains are extremely rare — typically 1-3 per year in the wild
The cost of a sandbox escape alone exceeds most threat actors' budgets

Detection/coverage: EDR agents detect sandbox escape attempts via anomalous child process creation, unexpected syscalls from chrome helper processes, or direct kernel object manipulation. Windows Defender Exploit Guard and Linux seccomp audit logs provide additional visibility.

03 · Compensating Control

HIGH 7.5→IGNORE 0.0

SEVERITY REDUCED

Push Chrome 155.0.8059.84+ via enterprise browser management immediately — The definitive fix. Use Chrome Browser Cloud Management, SCCM, Intune, or Jamf to force-update Chrome across the fleet. Verify via software inventory that all managed endpoints report ≥155.0.8059.84. Under the noisgate mitigation SLA for HIGH, deploy within 30 days — but Chrome auto-update means most endpoints will self-patch within 72 hours. Focus verification effort on endpoints with auto-update disabled or frozen channels.

HIGH 7.5→IGNORE 0.0

SEVERITY REDUCED

Disable Prerender via Chrome enterprise policy — Set the NetworkPredictionOptions policy to 2 (Network prediction disabled) via GPO or Chrome ADMX templates. This disables speculative prerendering entirely, removing the vulnerable code path. Trade-off: users lose prerender-based page load acceleration (~100–300ms on predicted navigations). This is a targeted mitigation if you cannot patch immediately. Deploy within 30 days per the noisgate mitigation SLA for HIGH.

HIGH 7.5→LOW 2.5

SEVERITY REDUCED

Deploy or verify Remote Browser Isolation for high-value users — RBI solutions (Zscaler Browser Isolation, Menlo Security, Island Enterprise Browser) execute web content in a cloud or on-prem isolation layer. Even if the UAF fires, it executes in the isolation container — not on the endpoint. Prioritize for executives, finance, legal, and any role accessing sensitive SaaS applications. This also defends against the hypothetical sandbox-escape chain.

HIGH 7.5→MEDIUM 5.5

SEVERITY REDUCED

Audit and restrict browsing on privileged endpoints — Domain controllers, jump hosts, CI/CD servers, and backup infrastructure should not run interactive browsers. Enforce via AppLocker / WDAC (Windows) or application allowlisting (Linux) to block chrome.exe / google-chrome on these hosts. This eliminates the highest-value attack surface for this and all future browser CVEs.

What doesn't work

Network IDS/IPS (Snort, Suricata): The exploit payload is delivered over HTTPS. Without TLS interception, network sensors cannot inspect the HTML/JS content that triggers the UAF. Even with TLS interception, there is no signature for this exploit (no public PoC).
EDR behavioral detection alone: The exploit runs entirely within Chrome's legitimate renderer process. There is no process injection, no child process spawning, no file write — all hallmarks EDR looks for. EDR becomes relevant only at Step 5 (sandbox escape), which is not part of this CVE.
Multi-factor authentication: MFA protects authentication flows but does not prevent a browser from loading and prerendering a malicious page. The exploit triggers before any authentication decision.

04 · Intelligence Metadata

The supporting signals.

In-the-Wild Exploitation	None observed. Not listed in CISA KEV. No reports from Google TAG, Mandiant, or any threat intelligence vendor as of 2026-10-16. Google's advisory states no known active exploitation.
Proof of Concept	No public PoC. Checked pocindex.io, GitHub (no repos named CVE-2026-110922), ExploitDB, Nuclei templates, and VulnCheck XDB — all negative. The Chromium bug (crbug.com/568719351) is access-restricted. Given Chrome's UAF mitigations (MiraclePtr, CFI, ASLR), a weaponized PoC would require substantial effort.
EPSS Score	Not yet scored — CVE was published 2026-10-15 (1 day ago). FIRST EPSS model updates daily; expect an initial score within 48 hours. Historical Chrome renderer UAFs without exploitation typically land in the 5th–15th percentile (0.01–0.05 probability).
KEV Status	Not listed. No CISA KEV entry. No known due date for federal agencies.
CVSS Vector	`CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H` → 8.8 HIGH. Key: `S:U` (Scope Unchanged) correctly confines impact to the renderer sandbox. `UI:R` reflects the need for the victim to visit a trigger page, though Prerender's speculative loading makes this lighter than a direct click.
Affected Versions	All Google Chrome versions prior to 155.0.8059.84 on Windows, macOS, and Linux. Chromium-based browsers (Edge, Brave, Opera, Vivaldi) sharing the Prerender code path are also affected until they pull the upstream fix.
Fixed Versions	Chrome 155.0.8059.84 (Linux) / 155.0.8059.85 (Windows/macOS), released 2026-10-15. Microsoft Edge and other Chromium forks typically follow within 1–5 days.
Scanning / Exposure	Not applicable for external scanning — this is a client-side browser vulnerability, not a server-exposed service. Enterprise visibility via Chrome Enterprise Browser Management, SCCM/Intune software inventory, or osquery (`SELECT version FROM chrome_extensions` or binary version checks). Shodan/Censys/GreyNoise are not relevant for this CVE class.
Chromium Severity	Critical per Chromium's own severity guidelines (renderer RCE = Critical). This is higher than the CVSS-derived HIGH (8.8), reflecting Chromium's policy that any renderer code execution is Critical regardless of sandbox containment.
Reporter	Xinyang Ge, Anthropic — reported 2026-10-02. Ge has reported multiple Chrome vulnerabilities in 2026, including CVE-2026-110913 (credited as "assisted by Claude"), CVE-2026-106358, and CVE-2026-106347. Prolific researcher with deep Chromium internals knowledge.

Sources.

05 · The Call

Final Verdict

= UNCHANGED to HIGH (7.5/10)

Why this verdict

Sandbox containment caps real-world impact. The advisory explicitly states code execution occurs *inside* the sandbox. Without a second independent vulnerability (sandbox escape), the attacker cannot touch the OS, persist, move laterally, or escalate privileges. Impact is limited to renderer-process memory: page DOM, cookies, session tokens, and form data for sites loaded in the same renderer. This is meaningful but fundamentally different from host-level RCE.
Chrome auto-update dramatically shrinks the exposure window. Chrome's aggressive auto-update pipeline patches ~85–90% of the consumer install base within 48–72 hours of a stable-channel release. Enterprise-managed Chrome (via Chrome Browser Cloud Management or GPO) typically follows within 1–2 weeks. By the time any attacker could develop a reliable exploit for this UAF, the vast majority of targets will be patched.
MiraclePtr adds a hard exploitation barrier. As of Q3 2026, Chrome enforces MiraclePtr (BackupRefPtr) across all processes and platforms. This quarantines freed allocations when dangling raw_ptr<T> pointers exist, converting many UAFs from exploitable bugs to non-security crashes. The specific Prerender code path may bypass MiraclePtr coverage (otherwise Chromium wouldn't rate it Critical), but exploitation still requires navigating PartitionAlloc bucket layout, ASLR, and CFI — a months-of-research barrier with no public PoC available.
No exploitation, no PoC, 1-day-old disclosure. Zero evidence of in-the-wild exploitation. Not on CISA KEV. No public PoC on GitHub, pocindex.io, ExploitDB, or Nuclei. The bug is access-restricted in the Chromium tracker. Threat actors cannot exploit what they don't have.
Role multiplier: Chrome is a *client application*, not an identity, infrastructure, or supply-chain component. It runs on workstations (95%+ of deployments), some CI/CD pipelines (headless Chrome for testing, ~3–5%), and occasionally on jump hosts or privileged endpoints (<1%). On a workstation (typical role), sandboxed renderer RCE can steal session tokens and page data — meaningful but bounded. On a CI/CD server running headless Chrome, renderer compromise could leak test credentials or CI tokens visible in the renderer process, but the sandbox still blocks host access. On a domain controller or jump host where someone is browsing (bad practice, <0.5% of installs), the same sandbox constraint applies — no host compromise without a second bug. Chrome is NOT a canonical high-value-role component (it is not an IdP, hypervisor, PAM tool, CA, or network edge device). The blast radius is consistently host-bounded at best, renderer-bounded in practice. No high-value-role floor override is triggered.

Why not higher?

The Chromium team's own Critical rating reflects their policy that any renderer RCE is Critical — a conservative, worst-case stance that assumes chains exist. In isolation, this CVE delivers sandboxed code execution, not host compromise. Without a paired sandbox escape (which would be a separate CVE and a separate, extremely expensive exploit), the blast radius is limited to in-process data theft. Upgrading to CRITICAL would overstate the standalone impact and misallocate patching urgency relative to vulnerabilities that deliver actual host-level or network-level compromise.

Why not lower?

Despite the sandbox, renderer-level code execution is not trivial. An attacker with renderer access can steal authentication cookies, session tokens, autofilled credentials, and sensitive page content — enough to compromise SaaS accounts, exfiltrate data from web apps, or pivot via stolen OAuth tokens. The Prerender trigger mechanism is also unusually attacker-friendly: the victim doesn't need to click the malicious link, just visit a page referencing it. And while no PoC exists today, the 8.8 CVSS and Chromium Critical rating signal genuine exploitability. Dropping to MEDIUM would underweight the real data-theft impact and the possibility that a motivated actor (with access to the restricted bug report details) could weaponize this within weeks.

06 · Verification

Crowdsourced verification payload.

Run on each target endpoint (Linux or macOS) as any user — no root required. Usage: bash cve-2026-110922-check.sh. On Windows, check Chrome version via reg query "HKLM\SOFTWARE\Google\Chrome" /v version or PowerShell (Get-Item "$env:ProgramFiles\Google\Chrome\Application\chrome.exe").VersionInfo.FileVersion instead.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash
# CVE-2026-110922 Checker — Chrome Prerender Use-After-Free
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
set -uo pipefail

FIXED_VERSION="155.0.8059.84"

# Locate Chrome binary
CHROME=""
for candidate in google-chrome google-chrome-stable chromium-browser chromium; do
  if command -v "$candidate" &>/dev/null; then
    CHROME="$candidate"
    break
  fi
done

# macOS fallback
if [[ -z "$CHROME" && "$(uname -s)" == "Darwin" ]]; then
  APP="/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"
  [[ -x "$APP" ]] && CHROME="$APP"
fi

if [[ -z "$CHROME" ]]; then
  echo "UNKNOWN — Chrome not found on this host"
  exit 2
fi

# Extract version
INSTALLED=$("$CHROME" --version 2>/dev/null | grep -oE '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+' | head -1)

if [[ -z "$INSTALLED" ]]; then
  echo "UNKNOWN — could not determine Chrome version"
  exit 2
fi

# Compare versions using sort -V
version_gte() {
  # Returns 0 if $1 >= $2
  [[ "$(printf '%s\n%s' "$1" "$2" | sort -V | head -1)" == "$2" ]]
}

if version_gte "$INSTALLED" "$FIXED_VERSION"; then
  echo "PATCHED — Chrome $INSTALLED >= $FIXED_VERSION"
  exit 0
else
  echo "VULNERABLE — Chrome $INSTALLED < $FIXED_VERSION (CVE-2026-110922)"
  exit 1
fi