CVE-2026-2441

Detailed proof-of-concept and technical analysis for CVE-2026-2441, a Chrome CSS use-after-free vulnerability enabling sandboxed renderer RCE via crafted HTML pages.

Affected Versions

Root Cause

FontFeatureValuesMapIterationSource stored a raw pointer (const FontFeatureAliases* aliases_) to the internal FontFeatureAliases HashMap. When the map is mutated during iteration via set() or delete(), the HashMap rehashes — allocating new storage and freeing the old. The raw pointer becomes dangling, and the next FetchNextItem() call reads from freed memory.

Vulnerable Code Path

Fix

The fix replaces the raw pointer with a deep copy of the HashMap. Even if the original map rehashes, the iterator operates on its own copy, preventing the dangling pointer.

Proof of Concept

Usage

1. Open poc.html in a vulnerable Chrome version (< 145.0.7632.75)
2. The page will attempt to trigger the UAF through three different methods

Expected Results

How the PoC Works

The PoC is organized to show the exploitation chain in a clear and reproducible order. The first part creates the vulnerable Blink/CSS object, the second part triggers the iterator invalidation, and the final part simulates the post-exploitation effects in a safe academic environment.

Important note: the UAF trigger is implemented through real browser-exposed CSS/JavaScript APIs. The heap leak and exfiltration dashboard are intentionally controlled/simulated to avoid releasing a weaponized Chromium exploit.

Step 1:Creation of the vulnerable CSS structure

The payload first defines a CSS @font-feature-values rule:

This rule causes Blink to create an internal CSSFontFeatureValuesMap. In the vulnerable implementation, iteration over this map is unsafe because the iterator keeps a raw pointer to the internal FontFeatureAliases storage.

The JavaScript payload later obtains the map from the stylesheet:

At this point, the attacker-controlled page has a JavaScript handle to a browser object whose internal C++ implementation is vulnerable to iterator invalidation.

Step 2: Delayed execution of the UAF trigger

The trigger is not executed immediately. The PoC waits 800 ms before running the vulnerable sequence:

This delay is used for demo stability. It allows the page and the fake banking verification form to be rendered before the memory-corruption trigger runs. In a real drive-by scenario, the same trigger could also be launched automatically as soon as the malicious page loads.

Step 3 — Iterator creation and concurrent map mutation

The core UAF primitive is the following loop:

The vulnerability is triggered by the order of operations:

Step 4 — Controlled heap pressure instead of aggressive heap spray

The original aggressive strategy used a larger heap-spray-like loop, for example inserting hundreds of elements such as 512 new entries after each deletion. That creates stronger heap pressure and makes reallocation/reuse more likely.

For the live demo, this was reduced to only 4 mutation steps:

The reason is practical and pedagogical: the 512-element spray often made the renderer crash immediately. A crash is useful to prove availability impact, but it prevents the rest of the demonstration from showing the simulated data theft and attacker dashboard. The reduced version still demonstrates the vulnerable iterator-invalidation logic while keeping the browser stable enough for the live presentation.

Step 5 — Simulated heap pointer leak

A real weaponized UAF exploit would normally require a memory disclosure primitive to leak heap or V8 pointers and bypass ASLR. The demo does not implement a real arbitrary memory read. Instead, it generates a heap-like address from a predefined static range:

This value is a simulated heap leak:

• 0x55a000000000 is the fixed heap-like starting range used by the demo.
• Math.random() * 0x200000 adds a small randomized offset.
• base & ~0xfff aligns the address to a page boundary.

The purpose is to show what an ASLR-bypass leak would look like on the attacker dashboard without implementing an actual memory disclosure exploit.

Step 6 — Exfiltration to the local attacker backend

After the UAF trigger and the simulated heap leak, the PoC builds a payload containing the collected form input, browser-resident session data, DOM snippet, UAF status, and simulated heap leak. The payload is sent to the local attacker backend:

The local backend receives the data on POST /collect, stores it in memory, and forwards it to the attacker dashboard through Server-Sent Events (GET /events). This models the command-and-control/exfiltration phase of a real attack while remaining local and controlled.

Impact

Immediate (Sandbox-scoped)

• Arbitrary code execution within the renderer process sandbox
• Information disclosure — leak V8 heap pointers (ASLR bypass), read renderer memory contents
• Credential theft — read document.cookie, localStorage, sessionStorage, form input values
• Session hijacking — steal session tokens, exfiltrate via fetch() / WebSocket / sendBeacon()
• DOM manipulation — inject phishing forms, modify page content
• Keylogging — capture all keystrokes via addEventListener('keydown')

Chained (with Sandbox Escape)

When combined with a separate sandbox escape vulnerability:

Real-world exploit chains using similar browser UAFs:

• NSO Pegasus — WebKit UAF + sandbox escape + kernel exploit
• Intellexa Predator — Chrome UAF + Android kernel exploit
• APT-28 (Fancy Bear) — Chrome 0-day + Windows LPE chain

Attack Vector

This vulnerability is exploitable via drive-by download — no user interaction beyond visiting a malicious page is required:

• Malvertising — malicious ads served through legitimate ad networks
• Watering hole — compromise a site frequently visited by the target
• Spear phishing — send a crafted link via email or messaging

Mitigation

1. Update Chrome to >= 145.0.7632.75 (Windows/macOS) or >= 144.0.7559.75 (Linux)
2. Update Chromium-based browsers (Edge, Brave, Opera, Vivaldi) when vendor patches are available
3. Verify Site Isolation is enabled (chrome://flags/#site-isolation-trial-opt-out)
4. Monitor endpoints for Chrome versions below the fixed builds

Timeline

References

• Google Chrome Releases Blog
• NVD — CVE-2026-2441
• The Hacker News — Chrome Zero-Day Under Active Attack
• Chromium Issue Tracker (restricted)

Support

If you find this research useful, consider buying me a coffee:

Disclaimer

This proof of concept is provided for educational and authorized security research purposes only. Use of this PoC against systems without explicit permission is illegal and unethical. The author is not responsible for any misuse.

License

MIT