"Use after free in CSS" is a funny description to see.
w4yai•Feb 18, 2026
Why ?
8-prime•Feb 18, 2026
To me at least it reads funny because when I think of CSS I think of the language itself and not the accompanying tools that are then running the CSS.
Saying "Markdown has a CVE" would sound equally off.
I'm aware that its not actually CSS having the vulnerability but when simplified that's what it sounds like.
Tyr42•Feb 18, 2026
Funny you'd mention that, when Notepad had a CVE in it's markdown parsing recently.
maxloh•Feb 18, 2026
I think they meant something like the CSS parser, or the CSS Object Model (CSSOM).
bawolff•Feb 18, 2026
One of the other commenters wrote a post that said it was related to @font-feature-values
mpeg•Feb 18, 2026
"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.
waynesonfire•Feb 18, 2026
"Actually, you forgot Brave."
mpeg•Feb 18, 2026
I quoted directly from NIST, there's many other browsers and non-browsers that use chromium
waynesonfire•Feb 18, 2026
It was intended as a joke reference to the 2004 Kerry / Bush debate. It's not a coincidence that Google would leave off an ad-blocking variant of Chrome.
order-matters•Feb 18, 2026
they listed the top 3 most popular chromium browsers, covering 90%+ of chromium users
ipaddr•Feb 18, 2026
But not 90% of users here.
pear01•Feb 18, 2026
did you also take poland being omitted to be some sort of conspiracy? seems you missed the point of why that "Actually, you forgot..." moment became such a punchline. Like it or not Brave is a very niche browser with rather insignificant market share why you would expect them to be mentioned in the first place is entirely lost on me. there are dozens of chromium forks also with under 1% market share, should we be forced to mention them all?
sumtechguy•Feb 18, 2026
Steam and VSCode pop into my mind.
bicepjai•Feb 18, 2026
So basically Firefox is not affected ?
jsheard•Feb 18, 2026
Firefox and Safari are fine in this case, yeah.
DetroitThrow•Feb 18, 2026
It's pretty hard to have an accidental a use after free in the FireFox CSS engine because it is mostly safe Rust. It's possible, but very unlikely.
topspin•Feb 18, 2026
That came to my mind as well. CSS was one of the earliest major applications of Rust in FireFox. I believe that work was when the "Fearless Concurrency" slogan was popularized.
moritzwarhier•Feb 18, 2026
Firefox and Safari developers dared the Chromium team to implement :has() and Houdini and this is the result!
/s
hdgvhicv•Feb 18, 2026
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.
wvbdmp•Feb 18, 2026
Particularly weird impulse for technically inclined people…
Although I must admit to the guilty pleasure of gleefully using Chromium-only features in internal apps where users are guaranteed to run Edge.
autoexec•Feb 18, 2026
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 and less privacy for firefox users as Mozilla is now fully committed to trying to profit from the sale of firefox users personal data to advertisers.
ddtaylor•Feb 18, 2026
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.
linkregister•Feb 18, 2026
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.
jacquesm•Feb 18, 2026
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.
LunaSea•Feb 18, 2026
I don't think that Mozilla believes that their pet projects are what the use community wants. I think they just don't care. Google's check will clear next year anyways.
zozbot234•Feb 18, 2026
Firefox is safe from this because their CSS handling was the first thing they rewrote in Rust.
bawolff•Feb 18, 2026
I mean, even if it was written in c or c++, its unlikely two separate code bases would have the exact same use after feee vuln.
jacquesm•Feb 18, 2026
It's unlikely, but it does actually happen. I've seen more than one complete rewrite of something important that had exactly the same bug. And I'm very sure that those sources were not related somehow.
duozerk•Feb 18, 2026
> 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.
salviati•Feb 18, 2026
I think a big part of "criminally low" is that you'll make much more money selling it on the black market than getting the bounty.
consumer451•Feb 18, 2026
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.
arcfour•Feb 18, 2026
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?
kspacewalk2•Feb 18, 2026
Is it in fact illegal to sell a zero day exploit of an open source application or library to whoever I want?
IggleSniggle•Feb 18, 2026
Depends. Within the US, there are data export laws that could make the "whoever" part illegal. There are also conspiracy to commit a crime laws that could imply liability. There are also laws that could make performing/demonstrating certain exploits illegal, even if divulging it isn't. That could result in some legal gray area. IANAL but have worked in this domain. Obviously different jurisdictions may handle such issues differently from one another.
consumer451•Feb 18, 2026
Thanks, great answer. I was just thinking from a simple market value POV.
sailfast•Feb 18, 2026
What about $500K selling it to governments?
bell-cot•Feb 18, 2026
Issue 1: Governments which your own gov't likes, or ones which it doesn't? The latter has downsides similar to a black market sale.
Issue 2: Selling to governments generally means selling to a Creepy-Spooky Agency. Sadly, creeps & spooks can "get ideas" about their $500k also buying them rights to your future work.
duozerk•Feb 18, 2026
I read this often, and I guess it could be true, but those kinds of transaction would presumably go through DNM / forums like BF and the like. Which means crypto, and full anonymity. So either the buyer trusts the seller to deliver, or the seller trusts the buyer to pay. And once you reveal the particulars of a flaw, nothing prevents the buyer from running away (this actually also occurs regularly on legal, genuine bug bounty programs - they'll patch the problem discreetly after reading the report but never follow up, never mind paying; with little recourse for the researcher).
Even revealing enough details, but not everything, about the flaw to convince a potential buyer would be detrimental to the seller, as the level of details required to convince would likely massively simplify the work of the buyer should they decide to try and find the flaw themselves instead of buying. And I imagine much of those potential buyers would be state actors or organized criminal groups, both of which do have researchers in house.
The way this trust issue is (mostly) solved in drugs DNM is through the platform itself acting as a escrow agent; but I suspect such a thing would not work as well with selling vulnerabilities, because the volume is much lower, for one thing (preventing a high enough volume for reputation building); the financial amounts generally higher, for another.
The real money to be made as a criminal alternative, I think, would be to exploit the flaw yourself on real life targets. For example to drop ransomware payloads; these days ransomware groups even offer franchises - they'll take, say, 15% of the ransom cut and provide assistance with laundering/exploiting the target/etc; and claim your infection in the name of their group.
moring•Feb 18, 2026
> Even revealing enough details, but not everything, about the flaw to convince a potential buyer would be detrimental to the seller, as the level of details required to convince would likely massively simplify the work of the buyer should they decide to try and find the flaw themselves instead of buying.
Is conning a seller really worth it for a potential buyer? Details will help an expert find the flaw, but it still takes lots of work, and there is the risk of not finding it (and the seller will be careful next time).
> And I imagine much of those potential buyers would be state actors or organized criminal groups, both of which do have researchers in house.
They also have the money to just buy an exploit.
> The real money to be made as a criminal alternative, I think, would be to exploit the flaw yourself on real life targets. For example to drop ransomware payloads; these days ransomware groups even offer franchises - they'll take, say, 15% of the ransom cut and provide assistance with laundering/exploiting the target/etc; and claim your infection in the name of their group.
I'd imagine the skills needed to get paid from ransomware victims without getting caught to be very different from the skills needed to find a vulnerability.
chc4•Feb 18, 2026
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 market sales.
Maybe google is an exception (but then again, maybe that payout was part marketing to draw more researchers).
throwaway150•Feb 18, 2026
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?
hsbauauvhabzb•Feb 18, 2026
An increase in the average bug payout. Bounty programs pay low on average.
idiotsecant•Feb 18, 2026
A number better than what the exploit could be sold for on the black market
i_am_jl•Feb 18, 2026
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, but bug bounties are a buyer's market where there is only one buyer and pricing is opaque and dictated by the buyer.
So why would anyone ever take a bounty instead of selling on the black market? Risk! You might get arrested or scammed selling an exploit on the black market, black market buyers know that, so they price it in to offers.
seanw444•Feb 18, 2026
Not sure why you're getting downvoted. It's the unfortunate reality.
gbalduzzi•Feb 18, 2026
> 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
cwillu•Feb 18, 2026
One is a lament that the industry average is so low, and the other is… a lament that the industry average is so low. What's the problem?
wepple•Feb 18, 2026
> but demonstrating a reliable way to exploit them
Is this a requirement for most bug bounty programs? Particularly the “reliable” bit?
Yeah, but lets keeping downplaying use-after-free as something not worth eliminating in 21st century systems languages.
pheggs•Feb 18, 2026
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
staticassertion•Feb 18, 2026
Google already uses `cargo-vet` for rust dependencies.
pheggs•Feb 18, 2026
thats good, but it wont eliminate the risk
staticassertion•Feb 18, 2026
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?
pheggs•Feb 18, 2026
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
staticassertion•Feb 18, 2026
All mainstream package managers are built with zero forethought into security, as far as I can tell. I don't think any of them are any good at it at all, otherwise they wouldn't give arbitrary code execution with literally zero restrictions, ability to audit, etc.
That said, `cargo-vet` is easily the best tool for mitigating this that I am aware of and it exists for Rust and is actively maintained by Google, Mozilla, and many others. I think it's fine to say "Rust encourages using more dependencies" but it has to be acknowledged that Rust also brings with it the best in class tool for supply chain security.
Could it be better? Absolutely. God yes. Why is cargo giving access to `~/.ssh/` for every `build.sh`? Why do package managers not make any effort to sandbox? But that's life today.
kibwen•Feb 18, 2026
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.
JoeAltmaier•Feb 18, 2026
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.
stackghost•Feb 18, 2026
>With allocate/delete discipline, C can be fairly safe memory-wise (written a million lines of code in C)
The last 40-50 years have conclusively shown us that relying on the programmer to be disciplined, yourself included, does not work.
nagaiaida•Feb 18, 2026
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.
nemothekid•Feb 18, 2026
>can be fairly safe memory-wise (written a million lines of code in C)
We are currently in a thread, where a major application has a heap corruption error in its CSS parser, and it's not even rare for such errors to occur. This doesn't seem true.
>But automated package managers etc can bring in code under the covers, and you end up with something you didn't ask for.
Last year there was a backdoor inserted into xz that was only caught because someone thought their CPU usage a little too high. I don't think the whole "C is safer because people don't use dependencies" is actually sound.
cogman10•Feb 18, 2026
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).
skydhash•Feb 18, 2026
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.
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
dbdr•Feb 18, 2026
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).
pheggs•Feb 18, 2026
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
kibwen•Feb 18, 2026
> 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 compiler.
pheggs•Feb 18, 2026
I know it's a sensitive topic for a lot of people, but as I said, I love rust. I don't know a lot of rust projects though that don't use any dependencies. In my humble opinion, disregarding the risks of such supply chain attacks is at least as bad as people disregarding the risk of memory unsafe code. But keep in mind, I'm not saying don't use rust.
mamma_mia•Feb 18, 2026
mamma mia! one day anyhow and anyerror will be backdoored it's inevitable
bigfatkitten•Feb 18, 2026
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.
pjmlp•Feb 18, 2026
Unless of course they are using vcpkg, conan or FetchContent.
Most corporations are already using the likes of Nexus or JFrog Artifactory, regardless of the programming language.
jacquesm•Feb 18, 2026
It's not more complex in C or C++, you just have less of a culture of buying into a whole eco-system. C and C++ play nice with the build system that you bring, rather than that you are forced into a particular way of working.
It's 'just a compiler' (ok, a bit more than that). I don't need to use a particular IDE, a particular build system, a particular package manager or even a particular repository.
That is not to throw shade on those other languages, each to their own, but I just like my tools to stay in their lane.
Just like I have a drawer full of different hammers rather than one hammer with 12 different heads, a screwdriver, a hardware store and a drill attachment. I wouldn't know what to do with it.
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 we had the xz vuln not too long ago. C / C++ has the benefit of the culture not using as many dependencies but this is still a problem that exists. With the increase of code in the world due to ai this is a problem we're going to need to fix sooner rather than later.
I don't think the supply chain should be a blocker for using rust especially when once of the best C++ teams in the world with good funding struggles to always write perfect code. The chrome team has shown precedent for moving to rust safely and avoiding dependency hell, they'll just need to do it again.
They have hundreds of engineers many of which are very gifted, hell they can write their own dependencies!
deanc•Feb 18, 2026
Presumably this affects all electron apps which embed chrome too? Don’t they pin the chrome version?
comex•Feb 18, 2026
Yes, but it's only a vulnerability if the app allows rendering untrusted HTML or visiting untrusted websites, which most Electron apps don't.
StilesCrisis•Feb 18, 2026
It would also require a sandbox escape to be a meaningful vulnerability.
Unfortunately, "seen in the wild" likely means that they _also_ had a sandbox escape, which likely isn't revealed publicly because it's not a vulnerability in properly running execution (i.e., if the heap were not already corrupted, no vulnerability exists).
baq•Feb 18, 2026
I wonder if this was found with LLM assistance, if yes, with which one and is it a one-off or does it mark a start of a new era (I assume it does).
paavohtl•Feb 18, 2026
Absolutely nothing in the announcement or other publicly available source implies that, to my knowledge. Might as well speculate if a random passer-by on the street is secretly a martian.
MallocVoidstar•Feb 18, 2026
Devtools is seemingly partially broken in this version, if I have devtools open on a reasonably dynamic web app Chrome will crash within a minute or two
aapoalas•Feb 18, 2026
It's also been ridiculously slow for a month or two now :/ not a good time to be working on some relatively intricate performance optimisation with DevTools taking 1-4 seconds to even start the performance recording.
himata4113•Feb 18, 2026
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 what if css can be just as risky... time to also have no-style?
Honestly, pretty excited for the full report since it's either stupid as hell or a multi-step attack chain.
staticassertion•Feb 18, 2026
> 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 here we are.
I'll elaborate a bit. Things like sanitizers largely rely on test coverage. Google spends a lot of money on things like fuzzing, but coverage is still a critical requirement. For a massive codebase, gettign proper coverage is obviously really tricky. We'll have to learn more about this vulnerability but you can see how even just that limitation alone is sufficient to explain gaps.
masklinn•Feb 18, 2026
> Things like sanitizers largely rely on test coverage.
And not in a trivial “this line is traversed” way, you need to actually trigger the error condition at runtime for a sanitizer to see anything. Which is why I always shake my head at claims that go has “amazing thread safety” because it has the race detector (aka tsan). That’s the opposite of thread safety. It is, if anything, an admission to a lack of it.
josefx•Feb 18, 2026
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.
stackghost•Feb 18, 2026
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
StilesCrisis•Feb 18, 2026
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.
fulafel•Feb 18, 2026
Isn't this a wrongly editorialized title - "Reported by Shaheen Fazim on 2026-02-11" so more like 7-day.
Aachen•Feb 18, 2026
It refers to your many days software is available for, with zero implying it is not yet out so you couldn't have installed a new version and that's what makes it a risky bug
The term has long watered-down to mean any vulnerability (since it was always a zero-day at some point before the patch release, I guess is those people's logic? idk). Fear inflation and shoehorning seems to happen to any type of scary/scarier/scariest attack term. Might be easiest not to put too much thought into media headlines containing 0day, hacker, crypto, AI, etc. Recently saw non-R RCEs and supply chain attacks not being about anyone's supply chain copied happily onto HN
Edit: fwiw, I'm not the downvoter
nickelpro•Feb 18, 2026
It's original meaning was days since software release, without any security connotation attached. It came from the warez scene, where groups competed to crack software and make it available to the scene earlier and earlier. A week after general release, three days, same-day. The ultimate was 0-day software, software which was not yet available to the general public.
In a security context, it has come to mean days since a mitigation was released. Prior to disclosure or mitigation, all vulnerabilities are "0-day", which may be for weeks, months, or years.
It's not really an inflation of the term, just a shifting of context. "Days since software was released" -> "Days since a mitigation for a given vulnerability was released".
fulafel•Feb 18, 2026
Wikipedia: A zero-day (also known as a 0-day) is a vulnerability or security hole in a computer system unknown to its developers or anyone capable of mitigating it
This seems logical since by etymology of zeroday it should apply to the release (=disclosure) of a vuln.
bawolff•Feb 18, 2026
I think the implication in this specific context is that malicious people were exploiting the vuln in the wild prior to the fix being released
bitbasher•Feb 18, 2026
Maybe Chromium should also rewrite their rendering engine in Rust ;p
astrobe_•Feb 18, 2026
This doesn't affect the many browsers based on Chromium?
thinkingemote•Feb 18, 2026
"This vulnerability could affect multiple web browsers that utilize Chromium, including, but not limited to, Google Chrome, Microsoft Edge, and Opera"
gruez•Feb 18, 2026
It does, it's just that blog is for chrome so it doesn't mention other browsers.
iririririr•Feb 18, 2026
why on earth would you even assume somthing like this?
honestly curious. do you think "based on chrome" means they forked the engine and not just "applied some UI skin"?
ripbozo•Feb 18, 2026
I'd love to see what the PoC code looks like, of course after the patch has been rolled out for a few weeks.
this is insane! what other zero days are out there and being used
also this seems chromium only so it doesnt impact firefox ?
kykat•Feb 18, 2026
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?
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')
chc4•Feb 18, 2026
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. The fact that you still need a sandbox escape doesn't mean that it is harmless, especially since if it's being exploited in the wild that means whoever is using it probably does also have a sandbox escape they are pairing with it.
kykat•Feb 18, 2026
Thanks for the explanation. So much for AI making it easier to learn things!
cosmic_cheese•Feb 18, 2026
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 of resources than smart fridge integration or whatever other bells and whistles Google has most recently decided to tack onto Chrome.
StilesCrisis•Feb 18, 2026
Chromium is pretty aggressively fuzzed. There aren't a lot of dark corners that can't be reached via a sufficiently aggressive fuzzer.
13 Comments
Saying "Markdown has a CVE" would sound equally off. I'm aware that its not actually CSS having the vulnerability but when simplified that's what it sounds like.
That's pretty bad! I wonder what kind of bounty went to the researcher.
/s
It’s why Firefox and Safari as so important despite HN’a wish they’d go away.
Although I must admit to the guilty pleasure of gleefully using Chromium-only features in internal apps where users are guaranteed to run Edge.
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 and less privacy for firefox users as Mozilla is now fully committed to trying to profit from the sale of firefox users personal data to advertisers.
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.
Selling preferential search access is legally precarious due to FTC's lawsuit against Mozilla.
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'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.
Issue 2: Selling to governments generally means selling to a Creepy-Spooky Agency. Sadly, creeps & spooks can "get ideas" about their $500k also buying them rights to your future work.
Even revealing enough details, but not everything, about the flaw to convince a potential buyer would be detrimental to the seller, as the level of details required to convince would likely massively simplify the work of the buyer should they decide to try and find the flaw themselves instead of buying. And I imagine much of those potential buyers would be state actors or organized criminal groups, both of which do have researchers in house.
The way this trust issue is (mostly) solved in drugs DNM is through the platform itself acting as a escrow agent; but I suspect such a thing would not work as well with selling vulnerabilities, because the volume is much lower, for one thing (preventing a high enough volume for reputation building); the financial amounts generally higher, for another.
The real money to be made as a criminal alternative, I think, would be to exploit the flaw yourself on real life targets. For example to drop ransomware payloads; these days ransomware groups even offer franchises - they'll take, say, 15% of the ransom cut and provide assistance with laundering/exploiting the target/etc; and claim your infection in the name of their group.
Is conning a seller really worth it for a potential buyer? Details will help an expert find the flaw, but it still takes lots of work, and there is the risk of not finding it (and the seller will be careful next time).
> And I imagine much of those potential buyers would be state actors or organized criminal groups, both of which do have researchers in house.
They also have the money to just buy an exploit.
> The real money to be made as a criminal alternative, I think, would be to exploit the flaw yourself on real life targets. For example to drop ransomware payloads; these days ransomware groups even offer franchises - they'll take, say, 15% of the ransom cut and provide assistance with laundering/exploiting the target/etc; and claim your infection in the name of their group.
I'd imagine the skills needed to get paid from ransomware victims without getting caught to be very different from the skills needed to find a vulnerability.
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?
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, but bug bounties are a buyer's market where there is only one buyer and pricing is opaque and dictated by the buyer.
So why would anyone ever take a bounty instead of selling on the black market? Risk! You might get arrested or scammed selling an exploit on the black market, black market buyers know that, so they price it in to offers.
I like to believe there are also ethics involved in most cases
Is this a requirement for most bug bounty programs? Particularly the “reliable” bit?
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?
That said, `cargo-vet` is easily the best tool for mitigating this that I am aware of and it exists for Rust and is actively maintained by Google, Mozilla, and many others. I think it's fine to say "Rust encourages using more dependencies" but it has to be acknowledged that Rust also brings with it the best in class tool for supply chain security.
Could it be better? Absolutely. God yes. Why is cargo giving access to `~/.ssh/` for every `build.sh`? Why do package managers not make any effort to sandbox? But that's life today.
The last 40-50 years have conclusively shown us that relying on the programmer to be disciplined, yourself included, does not work.
We are currently in a thread, where a major application has a heap corruption error in its CSS parser, and it's not even rare for such errors to occur. This doesn't seem true.
>But automated package managers etc can bring in code under the covers, and you end up with something you didn't ask for.
Last year there was a backdoor inserted into xz that was only caught because someone thought their CPU usage a little too high. I don't think the whole "C is safer because people don't use dependencies" is actually sound.
https://github.com/casey/just/blob/master/Cargo.toml
That’s just asking for trouble down the line.
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 compiler.
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.
Most corporations are already using the likes of Nexus or JFrog Artifactory, regardless of the programming language.
It's 'just a compiler' (ok, a bit more than that). I don't need to use a particular IDE, a particular build system, a particular package manager or even a particular repository.
That is not to throw shade on those other languages, each to their own, but I just like my tools to stay in their lane.
Just like I have a drawer full of different hammers rather than one hammer with 12 different heads, a screwdriver, a hardware store and a drill attachment. I wouldn't know what to do with it.
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 we had the xz vuln not too long ago. C / C++ has the benefit of the culture not using as many dependencies but this is still a problem that exists. With the increase of code in the world due to ai this is a problem we're going to need to fix sooner rather than later.
I don't think the supply chain should be a blocker for using rust especially when once of the best C++ teams in the world with good funding struggles to always write perfect code. The chrome team has shown precedent for moving to rust safely and avoiding dependency hell, they'll just need to do it again.
They have hundreds of engineers many of which are very gifted, hell they can write their own dependencies!
Unfortunately, "seen in the wild" likely means that they _also_ had a sandbox escape, which likely isn't revealed publicly because it's not a vulnerability in properly running execution (i.e., if the heap were not already corrupted, no vulnerability exists).
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 what if css can be just as risky... time to also have no-style?
Honestly, pretty excited for the full report since it's either stupid as hell or a multi-step attack chain.
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.
I'll elaborate a bit. Things like sanitizers largely rely on test coverage. Google spends a lot of money on things like fuzzing, but coverage is still a critical requirement. For a massive codebase, gettign proper coverage is obviously really tricky. We'll have to learn more about this vulnerability but you can see how even just that limitation alone is sufficient to explain gaps.
And not in a trivial “this line is traversed” way, you need to actually trigger the error condition at runtime for a sanitizer to see anything. Which is why I always shake my head at claims that go has “amazing thread safety” because it has the race detector (aka tsan). That’s the opposite of thread safety. It is, if anything, an admission to a lack of it.
> 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.
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
The term has long watered-down to mean any vulnerability (since it was always a zero-day at some point before the patch release, I guess is those people's logic? idk). Fear inflation and shoehorning seems to happen to any type of scary/scarier/scariest attack term. Might be easiest not to put too much thought into media headlines containing 0day, hacker, crypto, AI, etc. Recently saw non-R RCEs and supply chain attacks not being about anyone's supply chain copied happily onto HN
Edit: fwiw, I'm not the downvoter
In a security context, it has come to mean days since a mitigation was released. Prior to disclosure or mitigation, all vulnerabilities are "0-day", which may be for weeks, months, or years.
It's not really an inflation of the term, just a shifting of context. "Days since software was released" -> "Days since a mitigation for a given vulnerability was released".
This seems logical since by etymology of zeroday it should apply to the release (=disclosure) of a vuln.
honestly curious. do you think "based on chrome" means they forked the engine and not just "applied some UI skin"?
also this seems chromium only so it doesnt impact firefox ?
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')
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 of resources than smart fridge integration or whatever other bells and whistles Google has most recently decided to tack onto Chrome.