A Use-After-Free Bug in Chrome’s CSS Engine

The first zero-day of 2026 in Chromium-based browsers isn’t technically a pure CSS exploit, despite the headlines. CVE-2026-2441, patched in Chrome 145.0.7632.75, is a high-severity use-after-free vulnerability in the Blink CSS engine. A crafted HTML page could exploit it to execute arbitrary code inside a sandbox. Google credits researcher Shaheen Fazim for the report and acknowledges the exploit exists in the wild.

If that description makes you uneasy, you’re not alone. Friday the 13th release date aside, the phrase “use after free in CSS” sounds like CSS itself can now do system("rm -rf /"). That’s not what’s happening.

The CSS Isn’t the Malicious Part

Yes, the vulnerable code lives in Chrome’s Blink CSS engine, and the bug is triggered when the renderer turns CSS into a CSS Object Model. But the actual exploit is delivered via JavaScript. Validating CSS wouldn’t have prevented this, because the CSS involved is perfectly legitimate — it’s the memory handling around it that goes wrong.

Consider the CSS rule below, which affects font feature values:

@font-feature-values VulnTestFont {
  @styleset {
    entry_a: 1;
    entry_b: 2;
    entry_c: 3;
    entry_d: 4;
    entry_e: 5;
    entry_f: 6;
    entry_g: 7;
    entry_h: 8;
  }
}

When Blink parses this, it creates a CSSFontFeaturesValueMap object that gets added to document.styleSheets[0].cssRules. The bug was in how Chrome managed memory for the underlying HashMap that backs the JavaScript representation of that object. A malicious script could access freed memory, which by itself only causes a crash. But chained with other techniques, it becomes a full use-after-free exploit.

This isn’t a new kind of problem. @font-feature-values has been around since early 2023, yet it took until 2026 for someone to turn this particular flaw into a working end-to-end exploit. That pattern — old code, newly weaponizable condition — is common. Modern OS mitigations like address space layout randomization make reliable exploitation hard, and attackers often need to combine the freed memory access with type confusion to get code execution.

Pointers, Leashes, and Type Confusion

A simplified way to think about the mechanics: holding a pointer to an object is like holding a leash to your dog. After you free the dog, you still have the leash. An attacker swaps the dog for a cat (type confusion). When your code says “bark,” the cat does something it was trained to do instead — something malicious. The challenge is that in Chrome, an attacker can’t directly say “swap the cat.” They have to trigger low-level statements indirectly through the browser’s own APIs.

The Fix and the Bigger Pattern

Chrome’s one-line remedy is telling: instead of keeping a pointer to the underlying HashMap, Blink now works with a deep copy of it. That eliminates any chance of referencing freed memory.

Firefox has largely avoided this class of bug by rewriting its CSS engine in Rust, which handles memory safety automatically. Chromium has supported Rust since 2023, citing “safer (less complex C++ overall, no memory safety bugs in a sandbox either)” and the desire to “improve the security of Chrome.” The fact that use-after-free vulnerabilities keep recurring in Chromium’s C++ code suggests the gradual Rust migration isn’t moving fast enough to prevent future articles like this.