CVE-2026-2441: What You Need to Know About the Chrome CSSFontFeatureValuesMap Use-After-Free

Google Chrome is under active attack. CVE-2026-2441 is a high-severity use-after-free (UAF) vulnerability in Chrome's Blink CSS engine, carrying a CVSS score of 8.8. Confirmed by Google as actively exploited in the wild, this flaw allows a remote attacker to achieve arbitrary code execution inside the browser's renderer sandbox — with nothing more than a malicious web page and a single visit from the target. If your organization has not yet patched to Chrome 145.0.7632.75 (Windows/macOS) or 144.0.7559.75 (Linux), you are exposed right now.

Vulnerability Overview

The vulnerability resides in CSSFontFeatureValuesMap, a component of Chrome's Blink rendering engine responsible for handling CSS @font-feature-values rules. The flaw was reported by security researcher Shaheen Fazim on February 11, 2026, and Google shipped an emergency patch just two days later on February 13, simultaneously acknowledging in-the-wild exploitation.

  • CVE ID: CVE-2026-2441
  • CVSS: 8.8 (High)
  • Type: Use-After-Free (CWE-416)
  • Component: Blink CSS — CSSFontFeatureValuesMap
  • Source File: third_party/blink/renderer/core/css/css_font_feature_values_map.cc
  • In-the-Wild Exploitation: Confirmed by Google

Root Cause: A Dangling Pointer in the Iterator

Understanding why this vulnerability exists requires a brief look at how Chrome's FontFeatureValuesMapIterationSource manages memory. When an iterator is created over the internal FontFeatureAliases HashMap, it stores a raw pointer (const FontFeatureAliases* aliases_) to the HashMap's internal storage.

The problem arises when the map is mutated — via set() or delete() — while that iterator is still alive. A mutation triggers the HashMap to rehash: it allocates new backing storage and frees the old storage. The raw pointer held by the iterator now points to freed memory — a classic dangling pointer. When FetchNextItem() is subsequently called, it dereferences that freed memory, triggering the use-after-free condition.

The fix is elegantly simple: replacing the raw pointer (const FontFeatureAliases* aliases_) with a deep copy (const FontFeatureAliases aliases_). The iterator now operates on its own independent copy of the HashMap, so any rehash of the original map has no effect on the iterator's validity.

Affected Versions and Patch Status

The following Chrome versions are confirmed vulnerable. Organizations should audit their fleet immediately against these version thresholds:

  • Windows / macOS (Stable): Vulnerable below 145.0.7632.75 — patch to 145.0.7632.75 or later
  • Linux (Stable): Vulnerable below 144.0.7559.75 — patch to 144.0.7559.75 or later
  • Windows / macOS (Extended Stable): Vulnerable below 144.0.7559.177 — patch to 144.0.7559.177 or later
  • Chromium-based browsers (Edge, Brave, Opera, Vivaldi): Check individual vendor advisories — Vivaldi and Opera shipped fixes by February 16, 2026

How the Proof-of-Concept Exploit Works

A public proof-of-concept (PoC) demonstrates three independent methods to trigger the UAF, each paired with heap grooming techniques to make memory layout predictable for potential chained exploitation.

Method 1: entries() Iterator with Concurrent Mutation

An entries() iterator is created over the font feature map. On each step, the PoC calls iterator.next() to advance through the (now dangling) pointer, then immediately calls map.delete() to trigger a rehash, followed by 512 rapid map.set() calls to force heap reallocation into the freed region.

Method 2: for...of Loop with Concurrent Mutation

A standard for...of loop iterates the map while simultaneously deleting the current key and flooding the map with new entries — exploiting the same underlying iterator invalidation path through a different JavaScript surface.

Method 3: requestAnimationFrame with Forced Layout Recalc

This method interleaves iterator advancement with forced layout recalculation (document.body.offsetWidth) inside a requestAnimationFrame callback. This timing-sensitive approach is particularly relevant to real-world exploitation, where rendering pipeline side effects can be leveraged to influence heap state.

On unpatched Chrome versions, all three methods result in a renderer process crash with STATUS_ACCESS_VIOLATION (Windows) or SIGSEGV (Linux/macOS) — confirming the dangling pointer is dereferencing freed or unmapped memory.

Impact: From Renderer Crash to Full System Compromise

As a sandboxed renderer RCE, the immediate impact of CVE-2026-2441 is bounded by Chrome's sandbox — but that boundary is far from safe:

  • Arbitrary code execution within the renderer process
  • Memory disclosure — leaking V8 heap pointers to bypass ASLR
  • Credential theft — access to document.cookie, localStorage, sessionStorage, and form inputs
  • Session hijacking — exfiltration of session tokens via fetch(), WebSocket, or sendBeacon()
  • DOM manipulation — injection of phishing forms or malicious content
  • Keylogging — capture of all keystrokes via addEventListener('keydown')

When chained with a sandbox escape vulnerability, the impact escalates dramatically:

  • Renderer RCE (CVE-2026-2441) → Mojo IPC exploit → Browser process RCE → Kernel exploit → Full system compromise
  • Malware, ransomware, or spyware installation
  • File system access, lateral movement, and persistence mechanisms

This chain mirrors real-world nation-state exploit chains. NSO Group's Pegasus combined a WebKit UAF with a sandbox escape and kernel exploit. Intellexa's Predator paired a Chrome UAF with an Android kernel exploit. APT-28 (Fancy Bear) has deployed Chrome zero-days alongside Windows local privilege escalation chains. CVE-2026-2441 fits squarely in this threat model.

Attack Vector: Drive-By Download

No user interaction beyond visiting a malicious page is required. Threat actors can deliver this exploit through several well-established vectors:

  • Malvertising: Malicious ads served through legitimate ad networks on high-traffic sites
  • Watering hole attacks: Compromising sites regularly visited by high-value targets
  • Spear phishing: Sending crafted links via email or messaging platforms targeting specific individuals

Mitigation and Recommended Actions

There is one primary remediation: update Chrome immediately. Beyond patching, the following defensive measures reduce exposure and detection blind spots:

  • Update Chrome to 145.0.7632.75 or later (Windows/macOS) or 144.0.7559.75 or later (Linux)
  • Update all Chromium-based browsers (Edge, Brave, Opera, Vivaldi) as vendor patches become available
  • Verify that Site Isolation is enabled in Chrome (chrome://flags/#site-isolation-trial-opt-out) — this limits cross-origin data accessible within a compromised renderer
  • Monitor endpoints for Chrome versions below the fixed build numbers using your EDR or asset inventory
  • Consider blocking or alerting on processes spawned by Chrome renderer processes as a heuristic for sandbox escape activity

Timeline of Events

  • February 11, 2026: Vulnerability reported by Shaheen Fazim
  • February 13, 2026: Google releases Chrome 145.0.7632.75/76 (Windows/macOS) and 144.0.7559.75 (Linux)
  • February 13, 2026: Google publicly acknowledges in-the-wild exploitation
  • February 16, 2026: Vivaldi and Opera ship fixes for their Chromium-based builds

Conclusion

CVE-2026-2441 is a textbook high-severity browser zero-day: a memory-safety bug in a widely deployed, user-facing component, actively leveraged by threat actors before most defenders have had a chance to respond. The two-day turnaround from report to patch is a testament to Google's security team, but the confirmed in-the-wild exploitation means the window between vulnerability and compromise for unpatched systems is already open. Patch Chrome across your environment today, validate your Chromium-based browser inventory, and treat any unpatched instance as a live exposure. Browser security is endpoint security — and right now, the endpoint in question is every Chrome user below version 145.0.7632.75.