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…
Zero-day CSS: CVE-2026-2441 exists in the wild
111–120 of 242 posts
Re: Zero-day CSS: CVE-2026-2441 exists in the wild
#112Earlier 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?
Re: Zero-day CSS: CVE-2026-2441 exists in the wild
#113Earlier quoted context omitted.
> 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…
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.
Re: Zero-day CSS: CVE-2026-2441 exists in the wild
#114Earlier quoted context omitted.
A number better than what the exploit could be sold for on the black market
I don't believe those numbers will ever come close to converging, let alone bounty prices surpassing black market prices. It seems like these vulnerabilities will always be more valuable to people who can guarantee that their use will generate a return than to people who will use them to prevent a theoretical loss. Beyond that, selling zero-days is a seller's market where sellers can set prices and court many buyers,…
I like to believe there are also ethics involved in most cases
Re: Zero-day CSS: CVE-2026-2441 exists in the wild
#115Earlier 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
I'm sympathetic to the supply chain problem I even wrote a whole thing on it https://vincents.dev/blog/rust-dependencies-scare-me/ That being said as many above have pointed out you can choose not to bring in dependencies. The Chrome team already does this with the font parser library they limit dependencies to 1 or 2 trusted ones with little to no transitive dependencies. Let's not pretend C / C++ is immune to this…
The problem exists in C/C++ too, but the depth of dependencies are much smaller though, making the attack surface smaller, and damage gets spread to fewer products.
If I personally had to choose between a product written in C without dependencies to run on openbsd versus the same product written in rust with a few dependencies I would probably choose the C implementation. Even if there is a memory bug, if the underlying system is right they are extremely difficult/expensive to exploit. Abusing a supply chain on the other hand is very easy
Re: Zero-day CSS: CVE-2026-2441 exists in the wild
#116Earlier quoted context omitted.
HN doesn't want firefox to go away. HN wants firefox to be better, more privacy/security focused, and to stop trying to copy chrome out of the misguided hope that being a poor imitation will somehow make it more popular. Sadly, mozilla is now an adtech company ( https://www.adexchanger.com/privacy/mozilla-acquires-anonym-... ) and by default firefox now collects your data to sell to advertisers. We can expect less an…
What would be an acceptable revenue model? Google Chrome has the same privacy profile with the exception that Google retains the data for their own ad platforms. Selling preferential search access is legally precarious due to FTC's lawsuit against Mozilla.
They could start with the one they've refused for ages even though many have asked for it. Let people directly donate to fund the development of firefox (as opposed to just giving mozilla money to funnel into any number of their other projects). They could even make money selling merch if they didn't tank the brand. Firefox could have a very nice niche to fill as a privacy focused browser for power users who desire customization and security, but sadly they don't seem interested in being that. For whatever reason they'd rather spend a fortune buying adtech from facebook employees and be a chrome clone that pushes ads and sells user data, and that isn't going to inspire support from users.
That said, I'm not convinced that every open source project needs to be profit generating. Many projects are hugely successful without resorting to ads. What makes it possible for VLC or even Arch Linux to thrive without advertising that couldn't work just as well for firefox? The solution is certainly not to turn Firefox into a project that their users no longer want to support or use at all, but that seems to be where they are headed by selling out their userbase.
Re: Zero-day CSS: CVE-2026-2441 exists in the wild
#117Earlier quoted context omitted.
I'm sympathetic to the supply chain problem I even wrote a whole thing on it https://vincents.dev/blog/rust-dependencies-scare-me/ That being said as many above have pointed out you can choose not to bring in dependencies. The Chrome team already does this with the font parser library they limit dependencies to 1 or 2 trusted ones with little to no transitive dependencies. Let's not pretend C / C++ is immune to this…
Yeah I am not saying don't use rust. But the average amount of dependencies used by a dependency makes a big difference in my opinion. The reality is, most people will use wast amounts of dependencies - especially in vibe coded environments, where LLMs try to save a few tokens. The problem exists in C/C++ too, but the depth of dependencies are much smaller though, making the attack surface smaller, and damage gets sp…
It's a culture problem and I still have hope we can change that. My big hope is that as more big players get into it, windows, linux, android, chome, we'll get high quality stand alone packages. Many of these products have to reach certain standards. We saw this recently with JPEGXL. It got accepted into chromium and they've been diligent as to not bring in additional external dependencies.
Projects like sudo-rs take the same approach. As always good engineers will make good code as more of a niche for rust gets carved out I belive we'll see an ecosystem more like c / cpp and less like nodejs (of course this is just my sepeculation)
Re: Zero-day CSS: CVE-2026-2441 exists in the wild
#118I 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…
Chromium is pretty aggressively fuzzed. There aren't a lot of dark corners that can't be reached via a sufficiently aggressive fuzzer.
Re: Zero-day CSS: CVE-2026-2441 exists in the wild
#119Earlier quoted context omitted.
Yeah I am not saying don't use rust. But the average amount of dependencies used by a dependency makes a big difference in my opinion. The reality is, most people will use wast amounts of dependencies - especially in vibe coded environments, where LLMs try to save a few tokens. The problem exists in C/C++ too, but the depth of dependencies are much smaller though, making the attack surface smaller, and damage gets sp…
But the thing is these DO get exploited in the wild we see that again and again in high value targets like operating systems. That's why apple and google go to such high extremes to work in things like bounds checking. ROP JOB chains have gotten good and LLMS are even able to help these days (if you have the bankroll) It's a culture problem and I still have hope we can change that. My big hope is that as more big pla…
Yes but so do supply chain attacks. I mean we both know there's never a way to be absolutely secure and it's all just about probability. The question is how to determine what product may have better chances. All I am saying is that I personally prioritize fewer dependencies over memory safety.
I like your optimism, which I unfortunately struggle to share. I believe the quality of code will go down, there will be a lot of vibe code, and in general inexperienced people who don't put in the cognitive effort to pay attention to it. As software gets cheaper with AI, it will also become increasingly difficult to find the good things in a sea of slop. A good time for all the security engineers though ;)
Re: Zero-day CSS: CVE-2026-2441 exists in the wild
#120Earlier quoted context omitted.
A number better than what the exploit could be sold for on the black market
I don't believe those numbers will ever come close to converging, let alone bounty prices surpassing black market prices. It seems like these vulnerabilities will always be more valuable to people who can guarantee that their use will generate a return than to people who will use them to prevent a theoretical loss. Beyond that, selling zero-days is a seller's market where sellers can set prices and court many buyers,…
Most* valuable exploits can be sold on the gray market - not via some bootleg forum with cryptocurrency scammers or in a shadowy back alley for a briefcase full of cash, but for a simple, taxed, legal consulting fee to a forensics or spyware vendor or a government agency in a vendor shaped trenchcoat, just like any other software consulting income.
The risk isn't arrest or scam, it's investment and time-value risk. Getting a bug bounty only requires (generally) that a bug can pass for real; get a crash dump with your magic value in a good looking place, submit, and you're done.
Selling an exploit chain on the gray market generally requires that the exploit chain be reliable, useful, and difficult to detect. This is orders of magnitude more difficult and is extremely high-risk work not because of some "shady" reason, but because there's a nonzero chance that the bug doesn't actually become useful or the vendor patches it before payout.
The things you see people make $500k for on the gray market and the things you see people make $20k for in a bounty program are completely different deliverables even if the root cause / CVE turns out to be the same.
*: For some definition of most, obviously there is an extant "true" crappy cryptocurrency forum black market for exploits but it's not very lucrative or high-skill compared to the "gray market;" these places are a dumping ground for exploits which are useful only for crime and/or for people who have difficulty doing even mildly legitimate business (widely sanctioned, off the grid due to personal history, etc etc.)
I see that someone linked an old tptacek comment about this topic which per the usual explains things more eloquently, so I'll link it again here too: https://news.ycombinator.com/item?id=43025038