Zero-day CSS: CVE-2026-2441 exists in the wild (chromereleases.googleblog.com)
209 points by idoxer 6 hours ago
mpeg 6 hours 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.
duozerk 5 hours 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.
clucas 34 minutes ago
Here is a comment that really helped me understand bug bounty payouts: https://news.ycombinator.com/item?id=43025038
naeioi 5 hours ago
The bounty could be very high. Last year one bug’s reporter was rewarded $250k. https://news.ycombinator.com/item?id=44861106
duozerk 5 hours ago
salviati 5 hours 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.
duozerk 5 hours ago
consumer451 5 hours ago
wepple 4 hours ago
> but demonstrating a reliable way to exploit them
Is this a requirement for most bug bounty programs? Particularly the “reliable” bit?
bicepjai 6 hours ago
So basically Firefox is not affected ?
hdgvhicv 5 hours 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.
autoexec 4 hours ago
jacquesm 2 hours ago
wvbdmp 4 hours ago
zozbot234 5 hours ago
Firefox is safe from this because their CSS handling was the first thing they rewrote in Rust.
bawolff 4 hours ago
jsheard 6 hours ago
Firefox and Safari are fine in this case, yeah.
DetroitThrow 5 hours 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.
topspin 5 hours ago
moritzwarhier 5 hours ago
deanc 4 hours ago
Presumably this affects all electron apps which embed chrome too? Don’t they pin the chrome version?
comex 4 hours 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.
waynesonfire 6 hours ago
"Actually, you forgot Brave."
mpeg 6 hours ago
I quoted directly from NIST, there's many other browsers and non-browsers that use chromium
sumtechguy 4 hours ago
waynesonfire 5 hours ago
pjmlp 5 hours ago
Yeah, but lets keeping downplaying use-after-free as something not worth eliminating in 21st century systems languages.
pheggs 5 hours 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
kibwen 5 hours ago
vsgherzi 2 hours ago
cogman10 5 hours ago
staticassertion 5 hours ago
StilesCrisis 33 minutes 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).
cosmic_cheese an hour 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.
StilesCrisis 27 minutes ago
Chromium is pretty aggressively fuzzed. There aren't a lot of dark corners that can't be reached via a sufficiently aggressive fuzzer.
kykat 3 hours 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')
chc4 3 hours 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.
kykat 3 hours ago
Thanks for the explanation. So much for AI making it easier to learn things!
tripplyons 6 hours ago
"Use after free in CSS" is a funny description to see.
maxloh 5 hours ago
I think they meant something like the CSS parser, or the CSS Object Model (CSSOM).
bawolff 4 hours ago
One of the other commenters wrote a post that said it was related to @font-feature-values
w4yai 5 hours ago
Why ?
8-prime 5 hours 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.
Tyr42 3 hours ago
bitbasher 5 hours ago
Maybe Chromium should also rewrite their rendering engine in Rust ;p
himata4113 5 hours 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.
staticassertion 5 hours 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 4 hours 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.
josefx 4 hours 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.
StilesCrisis 17 minutes ago
stackghost 4 hours ago
ripbozo 5 hours 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 4 hours ago
Here's one: https://github.com/huseyinstif/CVE-2026-2441-PoC
agentifysh 3 hours ago
this is insane! what other zero days are out there and being used
also this seems chromium only so it doesnt impact firefox ?
astrobe_ 5 hours ago
This doesn't affect the many browsers based on Chromium?
gruez 4 hours ago
It does, it's just that blog is for chrome so it doesn't mention other browsers.
thinkingemote 4 hours ago
"This vulnerability could affect multiple web browsers that utilize Chromium, including, but not limited to, Google Chrome, Microsoft Edge, and Opera"
iririririr 2 hours 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"?
MallocVoidstar 6 hours 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 hours 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.
jijji 3 hours ago
use after free.... ahh the irony
fulafel 5 hours ago
Isn't this a wrongly editorialized title - "Reported by Shaheen Fazim on 2026-02-11" so more like 7-day.
Aachen 5 hours 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 hours 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".
fulafel 2 hours ago
bawolff 4 hours 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
baq 6 hours 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 hours 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.