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

181–190 of 242 posts

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

#181

Post by stevefan1999 »

bri3d wrote: post #130
clucas wrote: post #109

Earlier quoted context omitted.

Here is a comment that really helped me understand bug bounty payouts: https://news.ycombinator.com/item?id=43025038

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…

Just go with XMR

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

#182

Post by elternal_love »

StilesCrisis wrote: post #111
cosmic_cheese wrote: post #105

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…

Chromium is pretty aggressively fuzzed. There aren't a lot of dark corners that can't be reached via a sufficiently aggressive fuzzer.

Short answer: no. Long answer: There is a lot of Research about fuzzing, and there is a lot of incremental progress. We are not even at half here...

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

#183

Post by ceteia »

pjmlp wrote: post #179
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/…

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…

People made similar arguments regarding C++ versus Ada. The US military and defense industry even got something like a mandate in the 1990s to only write in Ada.

And then there was https://en.wikipedia.org/wiki/Ariane_flight_V88 , where US$370 million was lost. The code was written in Ada.

And using seat belts and wearing helmets do not help in those cases where 'unsafe' is used to take the seat belts and helmets off. And that is needed in Rust in a number of types of cases, such as some types of performance-sensitive code.

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

#184

Post by Imustaskforhelp »

qingcharles wrote: post #159
StilesCrisis wrote: post #111

Earlier quoted context omitted.

Chromium is pretty aggressively fuzzed. There aren't a lot of dark corners that can't be reached via a sufficiently aggressive fuzzer.

That's true, but isn't Chromium one of the largest and most complicated code bases in history? If you removed the drivers from Linux, which probably 99.9% aren't used in any specific hardware, then Chromium is far more LOC than the Linux kernel core even.

Chromium has so many LOC's of code and so much large in their size that it bypasses github limits.

What I mean by this is that github has a limit (in my understanding) on the sizes of public repos.

Chromium bypasses that & this is the reason why if you fork Chromium, you can get unlimited storage in github iirc

Github gets to start really wonky when you do this tho (iirc)

I can be wrong, I usually am but wanted to share this fact to just share the absurd scale of how large chromium is.

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

#185

Post by josefx »

tgv wrote: post #180
StilesCrisis wrote: post #113

Earlier quoted context omitted.

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)

I actually wasn't aware of that language. It was more a reference to the overblown claims Pike made in the early days of Go, where he presented it as the c++ replacement for everything Google.

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

#186

Post by keepamovin »

chc4 wrote: post #82
kykat wrote: post #80

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), rea…

Browser exploits are almost always two steps: you exploit a renderer bug in order to get arbitrary code execution inside a sandboxed process, and then you use a second sandbox escape exploit in order to gain arbitrary code execution in the non-sandboxed broker process. The first line of that (almost definitely AI generated) summary is the bad part, and means that this is one half of a full browser compromise chain. T…

[flagged]

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

#187

Post by 3oil3 »

jacquesm wrote: post #93
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 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.

I just want Firefox's search box to be on the top of the window so I don't have to bend my neck when I'm surfing in bed... I don't use it just for that.

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

#188

Post by keepamovin »

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…

"No-style" would break the modern web even more than No-Script does, unfortunately. CSS is just too integral to layout and functionality now.

A more robust alternative to disabling features is isolating where they execute. Instead of stripping out CSS/JS and breaking sites, you stream the browser session from a remote server.

If a zero-day like CVE-2026-2441 hits the parser, it crashes (or exploits) the remote instance, not your local machine. You get to keep the rich web experience (CSS, JS, fonts) without trusting your local CPU with the parsing logic. It’s basically "air-gapping" your browser tab. Not perfect, as attackers could still add a third step to compromise your remote and flow back to your local, but isolation like this adds defense in depth that then needs to compromise a much narrower attack surface (the local-remote tunnel) than if you ran it locally.

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

#189

Post by seanhunter »

comex wrote: post #65
deanc wrote: post #64

Earlier quoted context omitted.

Presumably this affects all electron apps which embed chrome too? Don’t they pin the chrome version?

Yes, but it's only a vulnerability if the app allows rendering untrusted HTML or visiting untrusted websites, which most Electron apps don't.

Lots of apps like slack and discord will show you an opengraph preview of a website if you post a link. I could of course be wrong but expect you could craft an exploit that just required you to be able to post the link - then it it would render the preview and trigger the problem.

Secondly as a sibling pointed out lots of apps have html ads so if you show a malicious ad it could also trigger. I’m old enough to remember the early google ads which which google made text-only specifically because google said that ads were a possible vector for malware. Oh how the turns have tabled.

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

#190

Post by bauruine »

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…

The NSA surely has ordered a backdoor.

>In December 2013, a Reuters news article alleged that in 2004, before NIST standardized Dual_EC_DRBG, NSA paid RSA Security $10 million in a secret deal to use Dual_EC_DRBG as the default in the RSA BSAFE cryptography library https://en.wikipedia.org/wiki/Dual_EC_DRBG

Post reply on HN