Google Chrome CVE-2026-6299: Brief Summary of a Critical Use After Free in Prerender

Introduction

A critical memory corruption flaw in Google Chrome's Prerender feature allows remote code execution through nothing more than a crafted HTML page, and the victim's browser can start running the malicious payload before the user even clicks a link. Chrome held roughly 66.7% of the global desktop browser market as of March 2026, so CVE-2026-6299 is a large exposure, and security teams need to address it promptly by patching or applying targeted workarounds.

Technical Information

Root Cause: Synchronous Destruction of a Live WebContents

CVE-2026-6299 is classified as CWE-416, Use After Free. The vulnerability is in Chrome's Prerender subsystem, in how PrerenderNewTabHandle was destroyed during certain cancellation paths.

Prerendering is a performance optimization. Chrome opens a page in a hidden background tab and fully executes its contents before the user navigates to it, so the page transition feels instant. Several mechanisms can trigger it:

• Speculation Rules API: Web developers embed JSON instructions in their pages telling Chrome which URLs to prerender.
• Omnibox Predictions: Chrome may automatically prerender a URL if it has high confidence the user will visit it, based on browsing history or search terms.
• Bookmark Hovering: Chrome may prerender a page when a user holds their pointer over a bookmark.

The bug is in lifetime management. When a prerender for a new tab was cancelled (for instance, by BrowsingDataRemoverImpl::RemoveImpl, which a Clear-Site-Data HTTP header can trigger), Chrome destroyed the PrerenderNewTabHandle and its owned WebContentsImpl synchronously. BrowsingDataRemoverImpl iterates over a snapshot of raw pointers to all live WebContents objects. Destroying one of those objects mid-iteration left a dangling pointer in the snapshot, a classic Use After Free condition.

Attack Flow

1. An attacker hosts a crafted HTML page designed to trigger the vulnerable code path in the Prerender component.
2. The victim's browser is induced to prerender this malicious page. This can happen through speculation rules on a page the victim visits, through Omnibox prediction if the attacker can influence browsing patterns, or through other prerender triggers.
3. During prerendering, the crafted page triggers a condition (such as a Clear-Site-Data header in a response) that causes BrowsingDataRemoverImpl::RemoveImpl to cancel the prerender.
4. The synchronous destruction of PrerenderNewTabHandle and its owned WebContentsImpl corrupts the raw pointer snapshot that BrowsingDataRemoverImpl is iterating over.
5. The attacker uses the resulting dangling pointer to achieve arbitrary code execution.

Because prerendered pages execute in the background, the malicious HTML can trigger the Use After Free and achieve code execution before the user explicitly clicks a link to the attacker-controlled destination. The CVSS v3.1 vector reflects this: network delivery, low attack complexity, no privileges required, and user interaction required (the user must visit a page that triggers the prerender).

Patch Information

Google fixed CVE-2026-6299 in commit 8c1ead5a699f53f1915f3187d2bcfac725c46815, authored by Hiroki Nakagawa ([email protected]) on March 30, 2026. The fix shipped in the Chrome 147.0.7727.101/.102 stable channel release on April 15, 2026. The commit was reviewed in Chromium Gerrit CL #7710193 and references Chromium bug 497053588. It modifies five files in the content/browser/preloading/prerender/ directory.

The fix restructures the destruction path in three ways.

1. Ownership Transfer via a New Static Method

The patch replaces the old instance method PrerenderNewTabHandle::CancelPrerendering() with a static method, CancelPrerenderingAndDestroy(), that explicitly takes ownership of the handle through std::unique_ptr. Because ownership moves into the static function, the caller can no longer access the object by accident after cancellation:

// Before (instance method, handle stays alive in caller's scope):
handle->CancelPrerendering(reason);

// After (static method consumes ownership):
PrerenderNewTabHandle::CancelPrerenderingAndDestroy(std::move(handle), reason);

2. Deferred Destruction via DeleteSoon()

For general cancellation cases, the new static method no longer destroys the handle immediately. It calls base::SingleThreadTaskRunner::GetCurrentDefault()->DeleteSoon(), which schedules the handle's destruction for the next message loop iteration. The WebContentsImpl that the handle owns then survives long enough for any in-progress iteration over raw WebContents pointers to finish safely:

// From prerender_new_tab_handle.cc — the core of the fix:
if (reason.final_status() == PrerenderFinalStatus::kSpeculationRuleRemoved) {
  // Defer destruction until the pagehide event is fired.
  registry.SchedulePendingDeletionPrerenderNewTabHandle(
      base::PassKey<PrerenderNewTabHandle>(), std::move(handle));
} else {
  // Defer destruction to avoid synchronous destruction of WebContentsImpl.
  // Prevents Use-After-Free during iteration (e.g., BrowsingDataRemoverImpl).
  base::SingleThreadTaskRunner::GetCurrentDefault()->DeleteSoon(
      FROM_HERE, std::move(handle));
}
registry.CancelHost(host_id, reason);

3. Consolidated Logic and PassKey Access Control

The branching logic for different cancellation reasons used to live inside PrerenderHostRegistry. The patch moves that decision into CancelPrerenderingAndDestroy, so lifetime management sits in one place. To support this, SchedulePendingDeletionPrerenderNewTabHandle changes from a private method on the registry to a public method guarded by base::PassKey<PrerenderNewTabHandle>, which means only PrerenderNewTabHandle itself can call the deferred deletion path:

// In prerender_host_registry.h — moved from private to public with PassKey guard:
void SchedulePendingDeletionPrerenderNewTabHandle(
    base::PassKey<PrerenderNewTabHandle>,
    std::unique_ptr<PrerenderNewTabHandle> handle);

The matching call site in prerender_host_registry.cc got much simpler. The old eight-line if/else block is now a single call that hands all lifetime decisions to the handle itself.

The commit also adds a browser test, NewTabPrerenderCancellationByBrowsingDataRemover, that exercises the exact trigger scenario. It starts a new-tab prerender, calls BrowsingDataRemover::RemoveAndReply(), and asserts that the prerender's WebContents is destroyed safely without a crash. The test directly confirms that the Clear-Site-Data and browsing data removal path no longer triggers the UAF.

Affected Systems and Versions

The vulnerability affects Google Chrome on all desktop platforms:

Any Chrome installation with the Preload pages setting enabled (the default) is exposed to this attack vector. Chromium-based browsers that include the affected Prerender code may also be vulnerable. Check each vendor's own advisory.

Vendor Security History

The Chromium project has a mature security program. Google runs a Vulnerability Reward Program that pays monetary awards and gives public credit for responsibly disclosed security flaws. During development, the project uses memory safety testing tools including AddressSanitizer, MemorySanitizer, UndefinedBehaviorSanitizer, Control Flow Integrity, and fuzzing engines such as libFuzzer and AFL.

Google follows a strict disclosure policy and keeps bug details and links restricted until a majority of users have updated to a fix. The Chromium issue tracker ticket for this vulnerability (497053588) remains restricted at the time of writing.

References

• NVD: CVE-2026-6299
• Chrome Releases: Stable Channel Update for Desktop (April 15, 2026)
• Chromium Issue Tracker: Bug 497053588
• Chromium Commit 8c1ead5a699f
• Chromium Commit Diff
• Chromium Gerrit CL #7710193
• Chrome Developer Docs: Prerender Pages
• Chrome Vulnerability Reward Program Rules
• Statcounter: Browser Market Share (March 2026)