An exploit… in CSS?! | CSS tricks

Okay, take a deep breath.

We will have fun understanding this vulnerability once you are sure that your browser is not affected, using the table below.

So you updated your browser and said a prayer. When you can string complete sentences together again, your first question is: Did CSS really have the dubious distinction of being the cause of that? the first zero-day exploit in Chromium-based browsers before 2026?

I mean, the Chrome Update Channel says they fixed a very serious vulnerability described as “[u]ser after gratis in CSS” … on Friday the 13th^e no less! If you can’t trust a release with such a description and date, what can you trust? Google credits security researcher Shaheen Fazim with reporting the exploit to Google. That guy’s LinkedIn says yes a professional insect hunterand I would say he deserves it highest possible bug bounty for finding something that a government agency says: “CSS in Google Chrome before 145.0.7632.75 allowed a remote attacker to execute arbitrary code in a sandbox via a crafted HTML page.”

Is this really a CSS exploit?

Something isn’t right. Even this security researcher swears by using CSS instead of JavaScriptso her security-minded readers don’t have to enable JavaScript when reading her blog. She trusts the security of CSS, even though she understands it enough to create a pure CSS x86 emulator (side note: woah). Until now, most of us have assumed that the potential security issues in CSS are relatively tame. We’re not suddenly living in a world where CSS can hijack someone’s operating system, are we?

Well, in my opinion, the headlines describing the bug as a CSS exploit in Chrome are a bit clickbait-ish, because they make it sound like a pure CSS exploit, as if malicious CSS and HTML would be enough to pull it off. If I’m honest, when I first skimmed those articles in the morning before rushing out to catch the train to work, the way the articles were worded reminded me of malicious CSS like:

.malicious-class {
  vulnerable-property: 'rm -rf *';
}

In the fictional, nightmare version of the bug that my ill-informed imagination conjured up, such a CSS could be ‘crafted’ to inject that shell command somewhere where it would be executed on the victim’s machine. Even as I reread the reports more carefully, they feel deliberately misleading, and that wasn’t just for me. My security-minded friend’s first question to me was, “But… isn’t CSS super validatable?” And then I dug deeper and discovered the CSS in the proof of concept because the exploit isn’t the malicious part, and therefore CSS validation wouldn’t have helped!

It doesn’t help the misunderstanding when the SitePoint article on CVE-2026-2441 bizarrely lies to its readers about what this exploit is, but instead describes another bug of medium severity that allows sending the displayed value of an input field to a malicious server by loading images in CSS. That’s not what this vulnerability is.

It’s not really a CSS exploit in the sense that JavaScript is the part that exploits the bug. I admit that the line of code that creates the condition necessary for a malicious script to perform this attack was present Blink from Google Chrome CSS engine component, but the CSS involved is not the malicious part.

How did the exploit work?

The CSS involvement in the exploit lies in the way Chrome’s rendering engine converts certain CSS into a CSS object model. Consider the CSS below:

@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 this CSS is parsed, a CSSFontFeaturesValueMap will be added to the collection of CSSRule objects in the document.styleSheets[0].cssRules. There was a bug in the way Chrome managed memory for the HashMap data structure underlying the JavaScript representation of the CSSFontFeaturesValueMapcausing a malicious script to inadvertently access memory that it shouldn’t. This in itself is not enough to cause damage other than browser crashing, but it can form the basis for a Use After Free (UAF) exploit.

Chrome’s description of the patch notes that “Google is aware that an exploit for CVE-2026-2441 exists in the wild,” although for obvious reasons they are coy about the details for a full end-to-end exploit. Worrying, @font-feature-values is not new – it has been available since early 2023 – but the discovery of an end-to-end UAF exploit may be recent. It would make sense if the code that created the possibility of this exploit is old, but someone has only recently realized a working exploit. If you look at this detailed explanation of a 2020 Use After Free vulnerability in Chrome within the WebAudio APIyou get the feeling that access to freed memory is just one piece of the puzzle in getting a UAF exploit working. Modern operating systems create hoops for attackers to jump throughwhich can make these types of attacks quite difficult.

Real-world examples of these types of vulnerabilities become complex, especially with a Chrome vulnerability where you can only activate low-level indirect instructions. But if you know C and want to understand the basics with a simplified example, you can try this coding challenge. Another way to help understand the ideas is this medium message about the recent Chrome CSSFontFeaturesValueMap exploitwhich contains a cute analogy in which the wiser to the object is like a leash that you still hold on to even after you release your dog, but an attacker hooks the leash to a cat instead (known as kind of confusion), so if you command your ‘dog’ to bark, the attacker is teaching his cat to think that the command ‘bark’ means he has to do something malicious instead.

The world is safe again, but for how long?

The one-line solution I mentioned that Chrome made was to change the Blink code to use a deep copy of the HashMap that underlies the CSSFontFeaturesValueMap instead of a reference to it, so there is no way to reference freed memory. In contrast, Firefox rewrote his CSS renderer in Rust and therefore tends to handle memory management automatically. Chrome started supporting the use of Rust since 2023. One of the motivations mentioned was “safer (less complex C++ in general, also no memory safety bugs in a sandbox)” and “improve safety (increase the number of lines of code without memory safety bugs, decrease the bug density of the code) of Chrome.” Since it appears that the UAF class of exploits in Chromium has returned over the years, and these vulnerabilities are often very serious when discovered, a more holistic approach to defending against such vulnerabilities may be necessary, so I don’t need to panic you with another article like this.