Home / Blog / CVE-2026-2441 Chrome Use-After-Free
CVE-2026-2441 • Chrome • Use-After-Free

Chrome Zero-Day: CSS Use-After-Free
Enables Sandboxed RCE in the Wild

February 2026 9 min read By Boney Warikozi
CVSS 8.8 High RCE Chrome Actively Exploited Zero-Day
⚠ Actively Exploited — Patch Immediately

Google has confirmed active in-the-wild exploitation of CVE-2026-2441. Update Chrome to 145.0.7632.75 or later (Windows/macOS) or 144.0.7559.75 or later (Linux) immediately. All Chromium-based browsers — Edge, Brave, Opera, Vivaldi — are also affected and require vendor updates.

Overview

CVE-2026-2441 is the first actively exploited zero-day in Google Chrome to be patched in 2026. The vulnerability is a use-after-free (UAF) memory safety flaw residing in Chrome's CSS engine — specifically within the CSSFontFeatureValuesMap implementation that manages CSS font feature values. A remote attacker can craft a malicious HTML page that triggers the UAF, ultimately gaining the ability to execute arbitrary code within Chrome's sandboxed renderer process.

Google's security team disclosed the flaw on February 16, 2026 — just five days after its discovery was reported by security researcher Shaheen Fazim. The unusually rapid patch turnaround reflects the severity of confirmed in-the-wild exploitation, though Google has deliberately withheld details about known threat actors and targeted entities to protect ongoing investigations.

The previous year, Google patched eight actively exploited Chrome zero-days. CVE-2026-2441 signals that 2026 is set to follow a similarly aggressive exploitation pace, and underscores the persistent targeting of browser engines as initial access vectors.

Technical Details

Use-After-Free: What It Means

A use-after-free vulnerability occurs when a program continues to access a region of memory after it has been freed. In C++ (the language Chrome is primarily written in), this can happen when an object is destroyed — releasing its heap allocation — but a dangling pointer to that memory still exists. If an attacker can control what data is placed at the freed memory location before the stale pointer is used again, they can corrupt program state or redirect execution flow.

In Chrome's Blink rendering engine, object lifetime management across its massive, multi-threaded codebase is notoriously complex. CSS layout and style recalculation involves a dense web of interacting object graphs, making it a historically fertile ground for UAF bugs.

Root Cause: CSSFontFeatureValuesMap Iterator Invalidation

The specific flaw is an iterator invalidation bug inside CSSFontFeatureValuesMap, the internal Chrome structure responsible for managing CSS @font-feature-values rule data. The @font-feature-values at-rule allows authors to define named font feature values for use with the font-variant-alternates property.

The bug manifests when the map is mutated (e.g., an entry is added or removed) while an iterator over that same map is still live. The iterator becomes a dangling reference pointing into freed or reallocated memory. A crafted HTML page containing malformed CSS that triggers this sequence causes the renderer to dereference the stale iterator, resulting in a heap use-after-free condition that is exploitable to gain code execution within the sandboxed renderer process.

Conceptual CSS Trigger Pattern
/* Simplified illustration of the at-rule structure involved */
@font-feature-values "MyFont" {
  @styleset {
    fancy: 1;
    classic: 2;
  }
}

/* Attacker triggers dynamic mutation of the CSSFontFeatureValuesMap
* while an active iterator is live — invalidating the iterator
* and creating a use-after-free condition in the renderer heap */
/* Full PoC details withheld by Google pending broad patch adoption */

Why "Sandboxed RCE" Still Matters

Google's description states the attacker "could execute arbitrary code inside a sandbox." Some may dismiss this as lower risk since the exploit is confined to Chrome's renderer sandbox and cannot directly access the host operating system. This framing is misleading for two reasons:

  • Sandbox escapes pair with UAFs: Sophisticated threat actors routinely chain renderer UAFs with separate sandbox escape bugs. CVE-2026-2441 by itself grants renderer code execution — a critical stepping stone toward full OS compromise when combined with a kernel or browser privilege escalation bug.
  • In-sandbox impact is still severe: The renderer sandbox still has access to session cookies, saved form data, password manager integrations, and active authenticated sessions in the browser. An attacker operating within the renderer can exfiltrate sensitive credentials and session tokens without escaping the sandbox.
⚠ Drive-By Attack Vector

CVE-2026-2441 requires no user interaction beyond visiting a malicious webpage. The attack can be weaponized through: a malicious link sent via phishing email, a compromised advertising network (malvertising), a watering hole attack targeting a specific organization's staff, or a malicious iframe embedded on a legitimate site. Browsing the web with an unpatched Chrome is sufficient to trigger exploitation.

Affected Versions & Platforms

The vulnerability affects Google Chrome across all major desktop platforms:

  • Windows & macOS: Chrome versions prior to 145.0.7632.75 / 145.0.7632.76
  • Linux: Chrome versions prior to 144.0.7559.75
  • All Chromium-based browsers: Microsoft Edge, Brave, Opera, Vivaldi, and any other browser built on the Chromium engine shares the underlying vulnerability. Each vendor must independently ship their own patched release based on the upstream Chromium fix.

Not affected: Firefox, Safari, and other non-Chromium browsers are not impacted by this specific CVE, though they may have their own separate vulnerabilities.

Timeline

  • February 11, 2026: Researcher Shaheen Fazim reports the vulnerability to Google
  • February 16, 2026: Google releases Chrome 145.0.7632.75/76 (Win/Mac) and 144.0.7559.75 (Linux) with the fix
  • February 16, 2026: Google confirms active in-the-wild exploitation in the patch advisory
  • February 2026: Vivaldi, Opera, and Edge vendors begin rolling Chromium upstream fix into their own releases

Detection & Verification

Check Your Chrome Version
# Navigate to in Chrome's address bar:
chrome://settings/help

# Or via CLI on Linux:
google-chrome --version
chromium-browser --version

# Patched versions (safe):
# Windows/macOS: >= 145.0.7632.75
# Linux: >= 144.0.7559.75

Enterprise Detection with Chrome Browser Cloud Management

Organizations using Google's Chrome Browser Cloud Management or similar MDM solutions can query enrolled device browser versions centrally. SIEM rules should alert on Chrome versions below the patched threshold discovered in software inventory scans (e.g., from endpoint agents).

Splunk — Detect Unpatched Chrome Versions
| inputlookup asset_inventory
| search browser_name="Chrome" OR browser_name="Chromium"
| eval patched=if(
    (os="Windows" OR os="macOS") AND version >= "145.0.7632.75", "yes", "no"
)
| where patched="no"
| table hostname, user, browser_name, version, os, last_seen

Remediation

The remediation steps for CVE-2026-2441 are straightforward but require immediate action given confirmed active exploitation:

  • Update Chrome immediately. Navigate to chrome://settings/help and Chrome will auto-detect and install the latest version. Restart Chrome to apply the update.
  • Update Chromium-based browsers. Patch Edge, Brave, Opera, and Vivaldi via their respective update mechanisms as soon as vendor patches are available. Check vendor security advisories for specific patched versions.
  • Enterprise managed deployments. Push the updated Chrome version via Group Policy, Intune, or your MDM solution. Do not wait for user-initiated updates in a confirmed active-exploitation scenario.
  • Enable automatic updates. Ensure Chrome's automatic update mechanism is not disabled by policy. Many enterprise configurations disable auto-updates for stability — this is a security anti-pattern that must be balanced against patch latency risk.

Zero Trust Perspective

CVE-2026-2441 illustrates why Zero Trust cannot be reduced to network controls alone. A user visiting a malicious web page on a fully network-segmented workstation can still have their browser compromised. The relevant Zero Trust controls that limit the blast radius of browser exploitation are:

  • Endpoint isolation: Run browsers in hardened, containerized environments (e.g., Remote Browser Isolation / RBI) so that renderer compromise is contained to a disposable virtual session.
  • Credential minimization: Avoid storing credentials in the browser or use hardware security keys (passkeys / FIDO2) so that an in-sandbox attacker cannot harvest usable authentication material.
  • Continuous endpoint verification: Zero Trust access platforms should enforce that browsers are up-to-date as a device health signal before granting access to internal applications.
  • Minimize browser privilege: Do not run browsers as domain admin or with elevated OS privileges. A sandboxed renderer exploit should not have pathways to sensitive enterprise resources through OS-level privilege alone.