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

171–180 of 242 posts

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

#171

Post by ceteia »

joshuamorton wrote: post #170
ceteia wrote: post #165

Earlier quoted context omitted.

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

But not "routinely".

How can you be sure? When I looked at for instance sudo-rs, it proclaimed loudly that it is memory safe, but its code has lots of unsafe.

https://github.com/trifectatechfoundation/sudo-rs

https://grep.app/search?f.repo=trifectatechfoundation%2Fsudo...

And Miri is very popular in Rust. Even if a Rust project doesn't have unsafe, sometimes people still run Miri with it, since dependencies might have messed up their unsafe usage.

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

#172

Post by ghusbands »

ceteia wrote: post #167
pjmlp wrote: post #18

Earlier quoted context omitted.

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

Yes, once you use 'unsafe' to bypass the safety model, you don't get safety.

Edit: If you reply with a reply, rather than edits, you don't get such confusion.

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

#173

Post by [deleted] »

ghusbands wrote: post #172
ceteia wrote: post #167

Earlier quoted context omitted.

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

Yes, once you use 'unsafe' to bypass the safety model, you don't get safety. Edit: If you reply with a reply, rather than edits, you don't get such confusion.

[deleted]

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

#174

Post by dbdr »

pheggs wrote: post #98
dbdr wrote: post #91

Earlier quoted context omitted.

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

Yes, but I believe that results in a cost/benefit analysis. If there are readily available rust crates that do something you need, and the cost of a possible vulnerability is not huge, most projects might decide (right or wrong) that it is worth it. It's an interesting question why projects tend to make different decisions in different languages, but it does not necessarily mean that you have to make the same decisions.

My point is that if you put a very high emphasis on avoiding vulnerabilities, you can either write the code in C with no/limited dependencies (and still risk memory safety bugs), or write the code in Rust with no/limited dependencies and no/limited unsafe code, and get much stronger guarantees for the same/less effort.

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

#175

Post by spragl »

Arch485 wrote: post #141
RyanShook wrote: post #134

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

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

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.

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

#176

Post by saagarjha »

streetfighter64 wrote: post #121
chc4 wrote: post #84

Earlier quoted context omitted.

I don't think you know anything about how these industries work and should probably read some of the published books about them, like "This Is How They Tell Me The World Ends", instead of speculating in a way that will mislead people. Most purchasers of browser exploits are nation-state groups ("gray market") who are heavily incentivized not to screw the seller and would just wire some money directly, not black marke…

I mean, you're still restricted to selling it to your own government, otherwise getting wired a cool $250k directly would raise a few red flags I think. And how many security researchers have a contact in some government-sponsored hacking company anyway? Do you really think that convincing them to buy a supposed zero-day exploit as a one-off would be easy? Say you're in the US. I'm sure there are some CIA teams or wh…

There are intermediate firms that will get the exploits passed to the right people. They are not very difficult to find.

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

#177

Post by saagarjha »

wepple wrote: post #51
duozerk wrote: post #17

Earlier quoted context omitted.

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

> but demonstrating a reliable way to exploit them Is this a requirement for most bug bounty programs? Particularly the “reliable” bit?

This depends on the program.

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

#178

Post by lesostep »

0xbadcafebee wrote: post #146
bri3d wrote: post #130

Earlier quoted context omitted.

Everyone should read this comment, it does a really eloquent job explaining the situation. The fundamental thing to understand is this: The things you hear about that people make $500k for on the gray market and the things that you see people make $20k for in a bounty program are completely different deliverables, even if the root cause bug turns out to be the same. Quoted gray market prices are generally for working…

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

Because collecting and gatekeeping vulns so you can attack other countries is bad manners. If you look up some of the Snowden testimonies, it's implied USA at least had access to some 0-days at the past, but nobody admitted to it, because it just bad national politics.

Even if USA is doing dog-shit in politics now, openly admitting to collecting cyber-weapons (instead of doing it silently) is just an open invitation to condemnation

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

#179

Post by pjmlp »

ceteia wrote: post #167
pjmlp wrote: post #18

Earlier quoted context omitted.

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

Those kind of arguments is like posting news about people still dying while wearing seat belts and helmets, ignoring the lifes that were saved by having them on.

By the way, I am having these kind of arguments since Object Pascal, back when using languages safer than C was called straighjacket programming.

Ironically, most C wannabe replacements are Object Pascal/Modula-2 like in the safety they offer, except we know better 40 years later for the use cases they still had no answer for.

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

#180

Post by tgv »

StilesCrisis wrote: post #113
josefx wrote: post #68

Earlier quoted context omitted.

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.

I don't think Go was ever planned to completely overtake C++. It is still a garbage collected language at the end of the day.

I think the parent tries to refer to Carbon: https://en.wikipedia.org/wiki/Carbon_(programming_language)
Post reply on HN