Zero-day CSS: CVE-2026-2441 exists in the wild

https://chromereleases.googleblog.com/2026/02/stable-channel-update-for-desktop_13.html

by idoxer • 5 months ago

379 217 5 months ago

chromereleases.googleblog.com

tripplyons• 5 months ago

"Use after free in CSS" is a funny description to see.

w4yai• 5 months ago

Why ?

8-prime• 5 months ago

To me at least it reads funny because when I think of CSS I think of the language itself and not the accompanying tools that are then running the CSS.

Saying "Markdown has a CVE" would sound equally off. I'm aware that its not actually CSS having the vulnerability but when simplified that's what it sounds like.

maxloh• 5 months ago

I think they meant something like the CSS parser, or the CSS Object Model (CSSOM).

bawolff3• 5 months ago

One of the other commenters wrote a post that said it was related to @font-feature-values

mpeg2• 5 months ago

"Google Chromium CSS contains a use-after-free vulnerability that could allow a remote attacker to potentially exploit heap corruption via a crafted HTML page. This vulnerability could affect multiple web browsers that utilize Chromium, including, but not limited to, Google Chrome, Microsoft Edge, and Opera."

That's pretty bad! I wonder what kind of bounty went to the researcher.

waynesonfire3• 5 months ago

"Actually, you forgot Brave."

mpeg2• 5 months ago

I quoted directly from NIST, there's many other browsers and non-browsers that use chromium

bicepjai2• 5 months ago

So basically Firefox is not affected ?

jsheard• 5 months ago

Firefox and Safari are fine in this case, yeah.

DetroitThrow• 5 months ago

It's pretty hard to have an accidental a use after free in the FireFox CSS engine because it is mostly safe Rust. It's possible, but very unlikely.

hdgvhicv3• 5 months ago

The listed browsers are basically skins on top of the same chromium base.

It’s why Firefox and Safari as so important despite HN’a wish they’d go away.

zozbot234• 5 months ago

Firefox is safe from this because their CSS handling was the first thing they rewrote in Rust.

dzhiurgis• 5 months ago

Yes, because nobody uses it

vntok• 5 months ago

No, though Firefox has its own CVE this week: https://thecyberexpress.com/firefox-v147-cve-2026-2447/

duozerk3• 5 months ago

That's pretty bad! I wonder what kind of bounty went to the researcher.

I'd be surprised if it's above 20K$.

Bug bounties rewards are usually criminally low; doubly so when you consider the efforts usually involved in not only finding serious vulns, but demonstrating a reliable way to exploit them.

salviati• 5 months ago

I think a big part of "criminally low" is that you'll make much more money selling it on the black market than getting the bounty.

naeioi• 5 months ago

The bounty could be very high. Last year one bug’s reporter was rewarded $250k. https://news.ycombinator.com/item?id=44861106

wepple• 5 months ago

but demonstrating a reliable way to exploit them

Is this a requirement for most bug bounty programs? Particularly the “reliable” bit?

clucas• 5 months ago

Here is a comment that really helped me understand bug bounty payouts: https://news.ycombinator.com/item?id=43025038

pjmlp7• 5 months ago

Yeah, but lets keeping downplaying use-after-free as something not worth eliminating in 21st century systems languages.

pheggs9• 5 months ago

I love rust but honestly I am more scared about supply chain attacks through cargo than memory corruption bugs. The reason being that supply chain attacks are probably way cheaper to pull off than finding these bugs

ceteia9• 5 months ago

https://materialize.com/blog/rust-concurrency-bug-unbounded-...

Edit: Replying to ghusbands:

'unsafe' is a core part of Rust itself, not a separate language. And it occurs often in some types of Rust projects or their dependencies. For instance, to avoid bounds checking and not rely on compiler optimizations, some Rust projects use vec::get_unchecked, which is unsafe. One occurrence in code is here:

https://grep.app/pola-rs/polars/main/crates/polars-io/src/cs...

And there are other reasons than performance to use unsafe, like FFI.

Edit2: ghusbands had a different reply when I wrote the above reply, but edited it since.

Edit3: Ycombinator prevents posting relatively many new comments in a short time span. And ghusbands is also wrong about his answer not being edited without him making that clear.

deanc• 5 months ago

Presumably this affects all electron apps which embed chrome too? Don’t they pin the chrome version?

comex• 5 months ago

Yes, but it's only a vulnerability if the app allows rendering untrusted HTML or visiting untrusted websites, which most Electron apps don't.

StilesCrisis3• 5 months ago

It would also require a sandbox escape to be a meaningful vulnerability.

Unfortunately, "seen in the wild" likely means that they _also_ had a sandbox escape, which likely isn't revealed publicly because it's not a vulnerability in properly running execution (i.e., if the heap were not already corrupted, no vulnerability exists).

staticassertion7• 5 months ago

I'd bet that the sandbox escape is just in the underlying operating system kernel and therefor isn't a matter for Chromium to issue a CVE.

baq• 5 months ago

I wonder if this was found with LLM assistance, if yes, with which one and is it a one-off or does it mark a start of a new era (I assume it does).

paavohtl• 5 months ago

Absolutely nothing in the announcement or other publicly available source implies that, to my knowledge. Might as well speculate if a random passer-by on the street is secretly a martian.

eks3912• 5 months ago

If you haven't seen news related to LLM generated bug reports, they are pretty disliked due to poor quality. So yes, a new LLM generated bug report era has begun, and the results so far have been moderator/developer burnout, increased time between real bugs being taken care of (as devs treat each submission as a true possible bug), and many projects no longer accepting bug reports. I have seen a couple anecdotal incidents when someone used LLMs to generate real bugs, one guy showing off a chain he made to HN, and that was really neat. LLMs aren't unable to make reports, but scammers and vibecoders see the dollar signs that they aren't going to put real effort in trying to get, and submit every response from a prompt similar to "provide me a bug report for [XX package/app]" in hopes that one pays out. The individuals I saw make real bug reports were already developers and were able to test out and iterate with the code the LLM provided, making connections of their own, just like any other person who uses LLMs responsibly instead of outsourcing thinking.

MallocVoidstar• 5 months ago

Devtools is seemingly partially broken in this version, if I have devtools open on a reasonably dynamic web app Chrome will crash within a minute or two

aapoalas• 5 months ago

It's also been ridiculously slow for a month or two now :/ not a good time to be working on some relatively intricate performance optimisation with DevTools taking 1-4 seconds to even start the performance recording.

himata4113• 5 months ago

The fact that these still show up is pretty wild to me. Don't we have a bunch of tools that should create memory-safish binaries by applying the same validation checks that memory-safe languages get for free purely from their design?

I get that css has changed a lot over the years with variables, scopes and adopting things from less/sass/coffee, but people use no-script for the reason because javascript is risky, but what if css can be just as risky... time to also have no-style?

Honestly, pretty excited for the full report since it's either stupid as hell or a multi-step attack chain.

staticassertion7• 5 months ago

Don't we have a bunch of tools that should create memory-safish binaries by applying the same validation checks that memory-safe languages get for free purely from their design?

No, we don't. All of the ones we have are heavily leveraged in Chromium or were outright developed at Google for similar projects. 10s of billions are spent to try to get Chromium to not have these vulnerabilities, using those tools. And here we are.

I'll elaborate a bit. Things like sanitizers largely rely on test coverage. Google spends a lot of money on things like fuzzing, but coverage is still a critical requirement. For a massive codebase, gettign proper coverage is obviously really tricky. We'll have to learn more about this vulnerability but you can see how even just that limitation alone is sufficient to explain gaps.

masklinn• 5 months ago

Things like sanitizers largely rely on test coverage.

And not in a trivial “this line is traversed” way, you need to actually trigger the error condition at runtime for a sanitizer to see anything. Which is why I always shake my head at claims that go has “amazing thread safety” because it has the race detector (aka tsan). That’s the opposite of thread safety. It is, if anything, an admission to a lack of it.

josefx2• 5 months ago

I heard they once created an entire language that would replace C++ in all their projects. Obviously they never rewrote Chrome in Go.

10s of billions are spent to try to get Chromium to not have these vulnerabilities, using those tools. And here we are.

Shouldn't pages run in isolated and sandboxed processes anyway? If that exploit gets you anywhere it would be a failure of multiple layers.

ceteia9• 5 months ago

No, we don't. All of the ones we have are heavily leveraged in Chromium or were outright developed at Google for similar projects. 10s of billions are spent to try to get Chromium to not have these vulnerabilities, using those tools. And here we are.

Chromium is filled with sloppy and old code. Some of the source code (at least if dependencies are included) is more than 20 years old, and a lot of focus has been on performance, not security.

Using Rust does not necessarily solve this. First, performance-sensitive code can require 'unsafe', and unsafe allows for memory unsafety, thus going back to square one, or further back. And second, memory safety isn't the only source of vulnerabilities. Rust's tagged unions and pattern matching help a lot with general program correctness, however, and C++ is lagging behind there.

keepamovin• 5 months ago

"No-style" would break the modern web even more than No-Script does, unfortunately. CSS is just too integral to layout and functionality now.

A more robust alternative to disabling features is isolating where they execute. Instead of stripping out CSS/JS and breaking sites, you stream the browser session from a remote server.

If a zero-day like CVE-2026-2441 hits the parser, it crashes (or exploits) the remote instance, not your local machine. You get to keep the rich web experience (CSS, JS, fonts) without trusting your local CPU with the parsing logic. It’s basically "air-gapping" your browser tab. Not perfect, as attackers could still add a third step to compromise your remote and flow back to your local, but isolation like this adds defense in depth that then needs to compromise a much narrower attack surface (the local-remote tunnel) than if you ran it locally.

fulafel3• 5 months ago

Isn't this a wrongly editorialized title - "Reported by Shaheen Fazim on 2026-02-11" so more like 7-day.

Aachen• 5 months ago

It refers to your many days software is available for, with zero implying it is not yet out so you couldn't have installed a new version and that's what makes it a risky bug

The term has long watered-down to mean any vulnerability (since it was always a zero-day at some point before the patch release, I guess is those people's logic? idk). Fear inflation and shoehorning seems to happen to any type of scary/scarier/scariest attack term. Might be easiest not to put too much thought into media headlines containing 0day, hacker, crypto, AI, etc. Recently saw non-R RCEs and supply chain attacks not being about anyone's supply chain copied happily onto HN

Edit: fwiw, I'm not the downvoter

nickelpro• 5 months ago

It's original meaning was days since software release, without any security connotation attached. It came from the warez scene, where groups competed to crack software and make it available to the scene earlier and earlier. A week after general release, three days, same-day. The ultimate was 0-day software, software which was not yet available to the general public.

In a security context, it has come to mean days since a mitigation was released. Prior to disclosure or mitigation, all vulnerabilities are "0-day", which may be for weeks, months, or years.

It's not really an inflation of the term, just a shifting of context. "Days since software was released" -> "Days since a mitigation for a given vulnerability was released".

bawolff3• 5 months ago

I think the implication in this specific context is that malicious people were exploiting the vuln in the wild prior to the fix being released

fulafel3• 5 months ago

It refers to your many days software is available for, with zero implying it is not yet out so you couldn't have installed a new version and that's what makes it a risky bug

Zero-day vulnerability or zero-day exploit refer to the vulnerability, not the vulnerable software. Hence by common sense the availability refers to the vulnerability info or the exploit code.

bitbasher• 5 months ago

Maybe Chromium should also rewrite their rendering engine in Rust ;p

silverwind• 5 months ago

They could just invest into Servo's and use that.

esprehn• 5 months ago

You joke, but a substantial portion of the Blink engine was (re)written in garbage collected C++ to a similar effect.

astrobe_2• 5 months ago

This doesn't affect the many browsers based on Chromium?

thinkingemote• 5 months ago

"This vulnerability could affect multiple web browsers that utilize Chromium, including, but not limited to, Google Chrome, Microsoft Edge, and Opera"

gruez• 5 months ago

It does, it's just that blog is for chrome so it doesn't mention other browsers.

iririririr2• 5 months ago

why on earth would you even assume somthing like this?

honestly curious. do you think "based on chrome" means they forked the engine and not just "applied some UI skin"?

astrobe_2• 5 months ago

The CVE itself only lists Chrome as the "affected software configuration", and I missed the line saying other browsers in the blog post, so I had a slight doubt. Other projects could use a drop-in replacement lib for the CSS, that's something one sees sometimes for other things (e.g. crypto libs - some projects have compile-time options ready for this).

ripbozo• 5 months ago

I'd love to see what the PoC code looks like, of course after the patch has been rolled out for a few weeks.

andreasley• 5 months ago

Here's one: https://github.com/huseyinstif/CVE-2026-2441-PoC

jijji• 5 months ago

use after free.... ahh the irony

agentifysh• 5 months ago

this is insane! what other zero days are out there and being used

also this seems chromium only so it doesnt impact firefox ?

mattstir• 5 months ago

Yeah, Firefox uses a different CSS engine that doesn't automatically have this same use-after-free.

kykat2• 5 months ago

I don't quite understand the vulnerability, when exploited, you can get information about the page from which the exploit code is running. Without a sandbox escape or XSS, that seems almost completely harmless?

This is the "impact" section on https://github.com/huseyinstif/CVE-2026-2441-PoC:

Arbitrary code execution within the renderer process sandbox Information disclosure — leak V8 heap pointers (ASLR bypass), read renderer memory contents Credential theft — read document.cookie, localStorage, sessionStorage, form input values Session hijacking — steal session tokens, exfiltrate via fetch() / WebSocket / sendBeacon() DOM manipulation — inject phishing forms, modify page content Keylogging — capture all keystrokes via addEventListener('keydown')

chc42• 5 months ago

Browser exploits are almost always two steps: you exploit a renderer bug in order to get arbitrary code execution inside a sandboxed process, and then you use a second sandbox escape exploit in order to gain arbitrary code execution in the non-sandboxed broker process. The first line of that (almost definitely AI generated) summary is the bad part, and means that this is one half of a full browser compromise chain. The fact that you still need a sandbox escape doesn't mean that it is harmless, especially since if it's being exploited in the wild that means whoever is using it probably does also have a sandbox escape they are pairing with it.

kykat2• 5 months ago

Thanks for the explanation. So much for AI making it easier to learn things!

cosmic_cheese• 5 months ago

I wonder how many bugs like this are lurking in the various dark corners of the Chromium/Blink codebase that nobody has taken a good, hard look at in a long time.

Given the staggering importance of the projects they should really have a full-time, well-staffed, well-funded, dedicated team combing through every line, hunting these things down, and fixing them before they have a chance to be used. It'd be a better use of resources than smart fridge integration or whatever other bells and whistles Google has most recently decided to tack onto Chrome.

StilesCrisis3• 5 months ago

Chromium is pretty aggressively fuzzed. There aren't a lot of dark corners that can't be reached via a sufficiently aggressive fuzzer.

anematode2• 5 months ago

Not sure about that one. Fuzzers have a hard time creating certain narrow preconditions that a manual review can find.

qingcharles2• 5 months ago

That's true, but isn't Chromium one of the largest and most complicated code bases in history? If you removed the drivers from Linux, which probably 99.9% aren't used in any specific hardware, then Chromium is far more LOC than the Linux kernel core even.

elternal_love• 5 months ago

Short answer: no. Long answer: There is a lot of Research about fuzzing, and there is a lot of incremental progress. We are not even at half here...

RyanShook• 5 months ago

I always wonder how many zero-days exist on purpose…

Arch485• 5 months ago

I've heard this sentiment a lot, that governments/secret agencies/whoever create zero-days intentionally, for their own use.

This is an interesting thought to me (like, how does one create a zero-day that doesn't look intentional?) but the more I think about it, the more I start to believe that this fully is not necessary. There are enough faulty humans and memory unsafe languages in the loop that there will always be a zero-day somewhere, you just need to find it.

(this isn't to say something like the NSA has never created or ordered the creation of a backdoor - I just don't think it would be in the form of an "unintentional" zero-day exploit)

taftster• 5 months ago

I'm not sure that governments actually create them, not prolifically at least. There's been some state actor influence over the years, for sure.

However, exploits that are known (only) by a state actor would most definitely be a closely guarded secret. It's only convenient for a state to release information about an exploit when either it's been made public or it has more consequences for not releasing.

So yes, exactly what you said. It's easier to find the exploits than to create them yourself. By extrapolation, you would have to assume that each state maintains its set of secret exploits, possibly never getting to use them for fear of the other side knowing of their existence. Cat & Mouse, Spy vs Spy for sure.

spragl• 5 months ago

I think you are right that the shady actors pretty much can use existing bugs.

But you are also right that this is not the only way they work. With the XZ Utils backdoor (2024), we normal nerds got an interesting glimpse into how they create a zero-day. It was luckily discovered by an american developer not looking for zero-days, just debugging a performance problem.

bauruine• 5 months ago

The NSA surely has ordered a backdoor.

In December 2013, a Reuters news article alleged that in 2004, before NIST standardized Dual_EC_DRBG, NSA paid RSA Security $10 million in a secret deal to use Dual_EC_DRBG as the default in the RSA BSAFE cryptography library https://en.wikipedia.org/wiki/Dual_EC_DRBG

kingforaday• 5 months ago

"Many of our security bugs are detected using AddressSanitizer, MemorySanitizer, UndefinedBehaviorSanitizer, Control Flow Integrity, libFuzzer, or AFL."

Interesting they are listing archived projects and not OSS-Fuzz. What's the reason for this?

squirrellous• 5 months ago

I thought OSS-fuzz still uses the aforementioned sanitizers and fuzz engines. It is not by itself a fuzzing engine.

superkuh• 5 months ago

When I try to look up the CVE/issue I get,

https://issues.chromium.org/issues/483569511 - [TBD][483569511] High CVE-2026-2441: Use after free in CSS. Reported by Shaheen Fazim on 2026-02-11

Access is denied to this issue. Access to this issue may be resolved by signing in.

hussainsumon018• 5 months ago

"Which reinforces the idea that this was optimized for porn" and I am almost hack online casino and hot photos from pussey or BOOBS... and put...

Zero-day CSS: CVE-2026-2441 exists in the wild

Related Stories