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

71–80 of 242 posts

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

#71

Post by nagaiaida »

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.

yes, people often invoke "simply write safer c" but that doesn't make it any more realistic of a proposition in aggregate as we keep seeing.

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

#72

Post by stackghost »

josefx wrote: post #68
staticassertion wrote: post #23

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

They do run in a sandbox, and this exploit gives the attacker RCE inside the sandbox. It is not in and of itself a sandbox escape.

However if you have arbitrary code execution then you can groom the heap with malloc/new to create the layout for a heap overflow->ret2libc or something similar

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

#73

Post by pheggs »

skydhash wrote: post #60
cogman10 wrote: post #34

Earlier quoted context omitted.

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

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

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

#74

Post by pheggs »

staticassertion wrote: post #27
pheggs wrote: post #24

Earlier quoted context omitted.

thats good, but it wont eliminate the risk

Nothing eliminates the risk but it is basically a best-in-class solution. If your primary concern is supply chain risk, there you go, best in class defense against it. If anything, what are you doing about supply chain for the existing code base? How is cargo worse here when cargo-vet exists and is actively maintained by Google, Mozilla, and others?

true, but rusts success in creating an easy to use dependency manager is the curse. In general rust software seems to use a larger amount of dependencies than c/c++ due to that, where each is at risk of becoming an attack vector. my prediction is that we will see some abuse of this in future, similar to what npm experienced

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

#76

Post by bigfatkitten »

skydhash wrote: post #60
cogman10 wrote: post #34

Earlier quoted context omitted.

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

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.

You also won’t typically find C/C++ developers blinding yolo’ing the latest version of a dependency from the Internet into their CI/CD pipeline.

They’ll stick with a stable version that has the features they need until they have a good reason to move. That version will be one they’ve decided to ship themselves, or it’ll be provided by someone like Debian or Red Hat.

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

#78

Post by consumer451 »

arcfour wrote: post #42
consumer451 wrote: post #31

Earlier quoted context omitted.

I am far from the halls of corporate decision making, but I really don't understand why bug bounties at trillion dollar companies are so low.

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?

Thanks, great answer. I was just thinking from a simple market value POV.

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

#79

Post by ddtaylor »

autoexec wrote: post #57
hdgvhicv wrote: post #41

Earlier quoted context omitted.

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

As a 25 year Firefox user this is spot on. I held out for 5 years hoping they would figure something out, but all they did was release weird stuff like VPNs and half baked services with a layer of "privacy" nail polish.

Brave is an example of a company doing some of the same things, but actually succeeding it appears. They have some kind of VPN thing, but also have Tor tabs for some other use cases.

They have some kind of integration with crypto wallets I have used a few times, but I'm sure Firefox has a reason they can't do that or would mess it up.

You can only watch Mozilla make so many mistakes while you suffer a worse Internet experience. The sad part is that we are paying the price now. All of the companies that can benefit from the Chrome lock in are doing so. The web extensions are neutered - and more is coming - and the reasons are exactly what you would expect: more ads and weird user hostile features like "you must keep this window in the foreground" that attempt to extract a "premium" experience from basic usage.

Mozilla failed and now the best we have is Brave. Soon the fingerprinting will be good enough Firefox will be akin to running a Tor browser with a CAPTCHA verification can for every page load.

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

#80

Post by kykat »

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

Post reply on HN