Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

chromereleases.googleblog.com

Post reply on HN
Print view View original

91–100 of 242 posts

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

#91

Post by dbdr »

pheggs wrote: post #73
skydhash wrote: post #60

Earlier quoted context omitted.

You’ll find more quality libraries in C because people don’t care about splitting them down to microscopic parcels. Even something like ‘just’ have tens of deps, including one to check that something is executable. https://github.com/casey/just/blob/master/Cargo.toml That’s just asking for trouble down the line.

yes, the average amount of dependencies used per dependency appears to be much larger in rust and thats what I meant and is worrying me. In theory C can be written in a memory safe manner, and in theory rust can be used without large junks of supply vulnerabilities. both of these are not the case in practice though

One difference is that it's an incredibly hard problem to check whether your C code is memory safe since every single line of your code is a risk. On the other hand, it's easy to at least assess where your supply vulnerabilities lie (read Cargo.toml), and you can enforce your policy of choice (e.g. whitelist a few specific dependencies only, vendor them, etc).

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

#92

Post by kibwen »

pheggs wrote: post #73
skydhash wrote: post #60

Earlier quoted context omitted.

You’ll find more quality libraries in C because people don’t care about splitting them down to microscopic parcels. Even something like ‘just’ have tens of deps, including one to check that something is executable. https://github.com/casey/just/blob/master/Cargo.toml That’s just asking for trouble down the line.

yes, the average amount of dependencies used per dependency appears to be much larger in rust and thats what I meant and is worrying me. In theory C can be written in a memory safe manner, and in theory rust can be used without large junks of supply vulnerabilities. both of these are not the case in practice though

> both of these are not the case in practice though

No, people routinely write Rust with no third-party dependencies, and yet people do not routinely write C code that is memory-safe. Your threat model needs re-evaluating. Also keep in mind that the most common dependencies (rand, serde, regex, etc) are literally provided by the Rust project itself, and are no more susceptible to supply chain attacks than the compiler.

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

#93

Post by jacquesm »

hdgvhicv wrote: post #41
bicepjai wrote: post #9

Earlier quoted context omitted.

So basically Firefox is not affected ?

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.

HN wants Firefox but with better stewardship and fewer misdirected funds.

Mozilla - wrongly - believes that the majority of FF users believe in Mozilla's hobby projects rather than that they care about their browser.

That's why - as far as I know - to this day it is impossible to directly fund Firefox. They'd rather take money from google than to be focusing on the one thing that matters.

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

#94

Post by jacquesm »

cogman10 wrote: post #34
pheggs wrote: post #19

Earlier quoted context omitted.

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

If you can bring in 3rd party libraries, you can be hit with a supply chain attack. C and C++ aren't immune, it's just harder to pull off due to dependency management being more complex (meaning you'll work with less dependencies naturally).

It's not more complex in C or C++, you just have less of a culture of buying into a whole eco-system. C and C++ play nice with the build system that you bring, rather than that you are forced into a particular way of working.

It's 'just a compiler' (ok, a bit more than that). I don't need to use a particular IDE, a particular build system, a particular package manager or even a particular repository.

That is not to throw shade on those other languages, each to their own, but I just like my tools to stay in their lane.

Just like I have a drawer full of different hammers rather than one hammer with 12 different heads, a screwdriver, a hardware store and a drill attachment. I wouldn't know what to do with it.

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

#95

Post by jacquesm »

bawolff wrote: post #63
zozbot234 wrote: post #43

Earlier quoted context omitted.

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

I mean, even if it was written in c or c++, its unlikely two separate code bases would have the exact same use after feee vuln.

It's unlikely, but it does actually happen. I've seen more than one complete rewrite of something important that had exactly the same bug. And I'm very sure that those sources were not related somehow.

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

#96

Post by idiotsecant »

throwaway150 wrote: post #70
duozerk wrote: post #38

Earlier quoted context omitted.

Maybe google is an exception (but then again, maybe that payout was part marketing to draw more researchers).

So is there anything that would actually satisfy crowd here? Offer $25K and it is "How dare a trillion dollar company pay so little?" Offer $250K and it is "Hmm. Exception! Must be marketing!" What precisely is an acceptable number?

A number better than what the exploit could be sold for on the black market

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

#97

Post by pheggs »

kibwen wrote: post #92
pheggs wrote: post #73

Earlier quoted context omitted.

yes, the average amount of dependencies used per dependency appears to be much larger in rust and thats what I meant and is worrying me. In theory C can be written in a memory safe manner, and in theory rust can be used without large junks of supply vulnerabilities. both of these are not the case in practice though

> both of these are not the case in practice though No, people routinely write Rust with no third-party dependencies, and yet people do not routinely write C code that is memory-safe. Your threat model needs re-evaluating. Also keep in mind that the most common dependencies (rand, serde, regex, etc) are literally provided by the Rust project itself, and are no more susceptible to supply chain attacks than the compile…

I know it's a sensitive topic for a lot of people, but as I said, I love rust. I don't know a lot of rust projects though that don't use any dependencies. In my humble opinion, disregarding the risks of such supply chain attacks is at least as bad as people disregarding the risk of memory unsafe code. But keep in mind, I'm not saying don't use rust.

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

#98

Post by pheggs »

dbdr wrote: post #91
pheggs wrote: post #73

Earlier quoted context omitted.

yes, the average amount of dependencies used per dependency appears to be much larger in rust and thats what I meant and is worrying me. In theory C can be written in a memory safe manner, and in theory rust can be used without large junks of supply vulnerabilities. both of these are not the case in practice though

One difference is that it's an incredibly hard problem to check whether your C code is memory safe since every single line of your code is a risk. On the other hand, it's easy to at least assess where your supply vulnerabilities lie (read Cargo.toml), and you can enforce your policy of choice (e.g. whitelist a few specific dependencies only, vendor them, etc).

I would argue that almost all major rust projects use dependencies. Checking the dependencies for vulnerabilities might be just as difficult as checking C code for memory safety, maybe even worse, because dependencies have dependencies and the amount of code to be checked can easily sky rocket. The problem gets even worse if you consider that not all rust code is safe, and that C libraries can be included and so on

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

#99

Post by bell-cot »

sailfast wrote: post #83
arcfour wrote: post #42

Earlier quoted context omitted.

Because it's nice to get $10k legally + public credit than it is to get $100k while risking arrest + prison time, getting scammed, or selling your exploit to someone that uses it to ransom a children's hospital?

What about $500K selling it to governments?

Issue 1: Governments which your own gov't likes, or ones which it doesn't? The latter has downsides similar to a black market sale.

Issue 2: Selling to governments generally means selling to a Creepy-Spooky Agency. Sadly, creeps & spooks can "get ideas" about their $500k also buying them rights to your future work.

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

#100

Post by nemothekid »

JoeAltmaier wrote: post #30
kibwen wrote: post #25

Earlier quoted context omitted.

But this is irrelevant. If you're afraid of third-party code, you can just... choose not to use third-party code? Meanwhile, if I'm afraid of memory corruption in C, I cannot just choose not to have memory corruption; I must instead simply choose not to use C. Meanwhile, Chromium uses tons of third-party Rust code, and has thereby judged the risk differently.

Maybe it's more complicated than that? With allocate/delete discipline, C can be fairly safe memory-wise (written a million lines of code in C). But automated package managers etc can bring in code under the covers, and you end up with something you didn't ask for. By that point of view, we reverse the conclusion.

>can be fairly safe memory-wise (written a million lines of code in C)

We are currently in a thread, where a major application has a heap corruption error in its CSS parser, and it's not even rare for such errors to occur. This doesn't seem true.

>But automated package managers etc can bring in code under the covers, and you end up with something you didn't ask for.

Last year there was a backdoor inserted into xz that was only caught because someone thought their CPU usage a little too high. I don't think the whole "C is safer because people don't use dependencies" is actually sound.

Post reply on HN