A high-severity use-after-free flaw in Google Chrome's Blink rendering engine, tracked as CVE-2026-2441 (CVSS 8.8), is being exploited in the wild. The bug lives in the CSSFontFeatureValuesMap component and lets a remote attacker run arbitrary code inside Chrome's renderer sandbox simply by luring a victim to a malicious web page — no clicks or downloads required. Google confirmed active exploitation and shipped an emergency fix; any deployment running below Chrome 145.0.7632.75 (Windows/macOS) or 144.0.7559.75 (Linux) remains exposed.

What the vulnerability is

CVE-2026-2441 is a use-after-free (CWE-416) in the code that handles CSS @font-feature-values rules. Security researcher Shaheen Fazim reported the issue to Google on February 11, 2026, and Google released a patched build just two days later, on February 13, at the same time confirming that attackers were already abusing it.

At a glance:

  • CVE ID: CVE-2026-2441
  • CVSS: 8.8 (High)
  • Class: Use-After-Free (CWE-416)
  • Affected component: Blink CSS — CSSFontFeatureValuesMap
  • Source file: third_party/blink/renderer/core/css/css_font_feature_values_map.cc
  • Exploitation status: Confirmed in-the-wild by Google

References: NVD entry for CVE-2026-2441 and the official CVE record.

Root cause: a stale pointer inside the iterator

The defect comes down to how Chrome's FontFeatureValuesMapIterationSource tracks memory. When an iterator is opened over the internal FontFeatureAliases HashMap, it caches a raw pointer to the map's backing storage:


const FontFeatureAliases* aliases_;

Trouble starts if the map is changed — through set() or delete() — while that iterator is still active. Mutating the map can force the HashMap to rehash, which allocates fresh backing storage and frees the old block. At that point the iterator's cached aliases_ pointer references memory that has already been released: a textbook dangling pointer. The next call to FetchNextItem() dereferences that freed allocation, and the use-after-free fires.

Google's patch is small but effective — it swaps the raw pointer for a value-type deep copy:


const FontFeatureAliases aliases_;

Because the iterator now owns an independent snapshot of the HashMap, any later rehash of the original map cannot invalidate it.

Affected builds and patch levels

Audit your fleet against the fixed version thresholds below:

  • Windows / macOS (Stable): vulnerable below 145.0.7632.75 — update to 145.0.7632.75 or newer
  • Linux (Stable): vulnerable below 144.0.7559.75 — update to 144.0.7559.75 or newer
  • Windows / macOS (Extended Stable): vulnerable below 144.0.7559.177 — update to 144.0.7559.177 or newer
  • Chromium-based browsers (Edge, Brave, Opera, Vivaldi): consult each vendor's advisory — Vivaldi and Opera both shipped fixes by February 16, 2026

Proof of concept

A public proof-of-concept (huseyinstif/CVE-2026-2441-PoC) reaches the use-after-free three different ways, each combined with heap-grooming so the freed slot is predictably reoccupied — the groundwork needed to turn a crash into a controllable exploit.

Method 1 — entries() iterator with concurrent mutation. The PoC opens an entries() iterator over the font-feature map. Each step calls iterator.next() to advance through the now-dangling pointer, then immediately calls map.delete() to provoke a rehash, followed by 512 rapid map.set() calls to push a fresh allocation into the just-freed region.

Method 2 — for...of loop with concurrent mutation. A normal for...of loop walks the map while the current key is deleted and new entries are flooded in — hitting the same iterator-invalidation path through a different JavaScript entry point.

Method 3 — requestAnimationFrame with forced layout recalculation. This variant interleaves iterator advancement with a forced layout recalc (document.body.offsetWidth) inside a requestAnimationFrame callback. The timing-sensitive approach is the most relevant to real attacks, since side effects of the rendering pipeline can be used to nudge heap state.

On unpatched Chrome, all three crash the renderer with STATUS_ACCESS_VIOLATION on Windows or SIGSEGV on Linux/macOS — confirmation that the dangling pointer is touching freed or unmapped memory.

Impact: from a renderer crash to full compromise

By itself, CVE-2026-2441 yields code execution confined to Chrome's renderer sandbox — but that confinement still leaves plenty of room for damage:

  • Arbitrary code execution within the renderer process
  • Memory disclosure, leaking V8 heap pointers to defeat ASLR
  • Credential theft via document.cookie, localStorage, sessionStorage, and form fields
  • Session hijacking by exfiltrating tokens through fetch(), WebSocket, or sendBeacon()
  • DOM tampering to inject phishing forms or malicious content
  • Keylogging through addEventListener('keydown')

Chained with a sandbox escape, the severity climbs sharply:

Renderer RCE (CVE-2026-2441) → Mojo IPC exploit → browser-process RCE → kernel exploit → full system compromise

That full chain opens the door to malware, ransomware, or spyware deployment, filesystem access, lateral movement, and persistence. It also mirrors documented nation-state tradecraft: NSO Group's Pegasus paired a WebKit UAF with a sandbox escape and kernel exploit, Intellexa's Predator combined a Chrome UAF with an Android kernel bug, and APT-28 (Fancy Bear) has fielded Chrome zero-days alongside Windows privilege-escalation chains. CVE-2026-2441 slots neatly into the same playbook.

Attack vector: drive-by

Exploitation needs nothing beyond a victim loading a malicious page. Common delivery routes include:

  • Malvertising — booby-trapped ads pushed through legitimate ad networks on busy sites
  • Watering-hole attacks — compromising sites that high-value targets routinely visit
  • Spear phishing — sending crafted links by email or chat to specific individuals

Detection and mitigation

Patching is the one indispensable action; the rest reduce exposure and close monitoring gaps:

  • Update Chrome to 145.0.7632.75 or later (Windows/macOS), or 144.0.7559.75 or later (Linux)
  • Update every Chromium-based browser (Edge, Brave, Opera, Vivaldi) as vendor patches land
  • Confirm Site Isolation is active via chrome://flags/#site-isolation-trial-opt-out to limit the cross-origin data reachable from a compromised renderer
  • Use your EDR or asset inventory to flag any Chrome below the fixed build numbers
  • Consider alerting on processes spawned by Chrome renderer processes as a heuristic for sandbox-escape behavior

Timeline

  • February 11, 2026 — Shaheen Fazim reports the vulnerability
  • February 13, 2026 — Google ships Chrome 145.0.7632.75/76 (Windows/macOS) and 144.0.7559.75 (Linux)
  • February 13, 2026 — Google publicly confirms in-the-wild exploitation
  • February 16, 2026 — Vivaldi and Opera release fixes for their Chromium builds

Bottom line

CVE-2026-2441 is a classic high-severity browser zero-day: a memory-safety bug in a near-ubiquitous, user-facing component, weaponized before most defenders could react. Google's two-day turnaround from report to patch is impressive, but confirmed in-the-wild abuse means the gap between disclosure and compromise is already open for anyone still unpatched. Roll out the Chrome update across your environment now, validate your Chromium-based browser inventory, and treat every instance below 145.0.7632.75 as a live exposure.