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

161–170 of 242 posts

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

#161

Post by 0xbadcafebee »

eks391 wrote: post #152
0xbadcafebee wrote: post #146

Earlier quoted context omitted.

Why is it the USA doesn't have their own bug bounty program for non-DOD systems? Like, sure, they have a bounty for vulns in govt systems. But why not accept vulns for any system, and offer to pay more than anyone else? It would give them a competitive advantage (offensive & defensive) over every other nation. End one experimental weapons program (or whatever garbage DOD spends its obscene budget on) and suddenly we'…

I think you are confusing bug bounty programs with espionage and cyber warfare. The USA definitely accepts vulnerabilities for any system (or at least target systems), paying good money for them if it is an attack chain, giving them that competitive edge you mention. They have at least one military organization over this exact thing (USCYBERCOM) and realistically other orgs to include the intelligence community. Ther…

But that's the thing, I think they specifically need a non-IC program. If I'm a white-hat, grey-hat, or a somewhat cagey black-hat, I'm not gonna reach out to a shadowy organization with a penchant for extrajudicial surveillance, torture & killing to make $50k on a bug. Sure, you can try your hand at selling them an exploit that won't get revealed. But if only you and The Company know about the bug, and it could mean the upside in a potential war (or just a feather in an agency head's cap), why would The Company keep you alive and able to talk about it? OTOH, if the program you're reporting to doesn't have a track record of illegal activity, personally I'd feel a lot safer reporting there. And ideally their mission would be to patch the bug and not hold onto it. But we get to patch first, so it's still our advantage.

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

#163

Post by ceteia »

zozbot234 wrote: post #43
bicepjai wrote: post #9

Earlier quoted context omitted.

So basically Firefox is not affected ?

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

Does the Rust implementation not use any unsafe and does not use libraries using unsafe?

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

#164

Post by moring »

array_key_first wrote: post #147
jacquesm wrote: post #93

Earlier quoted context omitted.

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.

HN, and firefox users, can never decide where the money should go or what the goals should be. The problem with producing the better product is the amount of in-fighting increases exponentially. Google produces a "fuck you got mine" type browser and everyone knows it, so nobody really cares when they make god awful privacy decisions or intentionally produce worst standards to try to fuck their customers up the ass in…

> HN, and firefox users, can never decide where the money should go or what the goals should be.

Without ever having dealt with this problem, it sounds like an embarrassingly solved problem, in the sense of: He who gives the money, decides where it goes.

The other half is to provide features that are actually detrimental if you don't want them as plug-ins / extensions / whatever. Pocket is an example for this. Firefox OS is not because it's not force-bundled with Firefox to begin with.

> They're switching to Chrome because they just don't care about being fucked up the ass, or worse, they secretly want to be.

The point where you stop trying to understand your users is the point where you start losing them.

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

#165

Post by ceteia »

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…

People also write Rust code that is not memory-safe.

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

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

#166

Post by squirrellous »

kingforaday wrote: post #143

"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?

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

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

#167

Post by ceteia »

pjmlp wrote: post #18
mpeg wrote: post #5

"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.

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

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.

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

#168

Post by gbalduzzi »

idiotsecant wrote: post #128
gbalduzzi wrote: post #114

Earlier quoted context omitted.

> So why would anyone ever take a bounty instead of selling on the black market? Risk! I like to believe there are also ethics involved in most cases

Systems that rely on ethical behaviour to function generally dont last long

That is why I said "also", it should not be the only factor.

The conversation was moving between two possibilities only: either collect bug bounties or sell on the black market. I believe most (again: most, not all) security researchers collecting bug bounties right now would not start selling on the black market in case bounties disappeared. They would change their focus to something else to sustain themselves

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

#169

Post by ceteia »

staticassertion wrote: post #23
himata4113 wrote: post #12

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…

> 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 he…

> 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.

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

#170

Post by joshuamorton »

ceteia wrote: post #165
kibwen wrote: post #92

Earlier quoted context omitted.

> 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…

People also write Rust code that is not memory-safe. https://materialize.com/blog/rust-concurrency-bug-unbounded-...

But not "routinely".
Post reply on HN