The CVE associated with it (CVE-2026-85046) is already being exploited in the wild. If we put our thinking caps on, how much do you think this vulnerability is actually worth? How much do you think an organization like Google would spend on, for example, AI tokens or compute to detect this internally before it was found and exploited in the wild?
Ethical disclosure is a complicated topic, because researchers shouldn't hold bugs for ransom or demand high payment. But at the same time, if someone submits a critical issue like this, it makes sense to pay them what the bug's actually worth. Why should a researcher be effectively penalized for responsibly telling a vendor instead of selling the bug to a "research firm" or three-letter agency?
It's one thing if you're an open source project maintainer just trying to put something out to the community. The math is a lot different if you're Google.
While I agree 1000 is hilariously low for this, worth is hard to quantify. Do you pay what it could theoretically cost your company? the amount the top bidding bad actor would be willing to pay?
Maybe some code is so important and heavily trafficked it becomes a public works project, and various legs can bid for pieces of the project, line how all infrastructure works.
Maybe needs a Good-Guy-Buy-It-Now w/instant delivery at a fair price. (OK that’s kind of a threat—you’re running an auction and you have the price the corp has to pay to avoid the auction ending.)
$1k is so dumb and the fact we’re discussing auctions is proof (hello, Sundar, what you doing over there?).
Guess this will change after the next e.g. nationwide hospital ransomware by a hacker who publicly laments bounty rates, if the news cycle accommodates the story long enough.
In the past I would have thought this would incentivize finding bugs that might never be found. However it is now clear that all bugs that can be found will be found. So this makes a ton of sense.
Has anyone actually been convicted of abetting a crime by selling a vulnerability, by itself, not conspiring with the buyer to commit a crime using said vulnerability? Not as far as I can see. It would be absurd to jail someone for accurately describing a bug.
Well, someone did decide to tell google about this in exchange for a thousand dollars (albeit unclear how much the money was the motivator). Doesn't that mean the market did decide in google's favour?
Someone decided to tell Google about this in exchange for an unknown amount of money, chosen unilaterally by Google at a later date, at which point the market value of the vulnerability is $0.
we really do not want to engineer a system in which using bugs to make money is considered economically legitimate activity. It is still crime. The main reason to report bugs and get the bounties for doing so is still because it makes the world safer and healthier. The money is there to make is to incentivize the work of finding and reporting them -- not to outbid the bad actors.
Companies sometimes reward their employees with important bug fixes. When I worked on a big dev team, we'd even decide what were the most important fixes and give people a special 5k bonus or something.
But they weren't security issues necessarily. I never thought about it, fixing a huge performance issue is big. A security fix that gets caught early makes no noise so you just don't know how important it would have been. We also once had a really terrible bug that lead to lots of customers getting effectively attacked.
"Crime" is very flexible term. One country's criminal is another country hero. Maybe the author would sell the vulnerability to an organization making exploits for government use.
"Safety" is also a relative thing, when the world is safer for one party, it is usually worse for another.
It's one thing to hold something for ransom ("give me $5M or I release the 0day"). It's another to sell a valuable piece of information ("give me $5M if you want the 0day"). As long as you're only offering the bug to the company who would be impacted by its release, there's nothing unethical about asking for payment.
Maybe you think that, ethically, all bugs should be reported, regardless of payment, because it prevents harm. Well a lot of things prevent harm that we don't all take it upon ourselves to do voluntarily. Should everyone do all safety-related work for free? If we don't want to do it for free, should we not do safety work at all?
If the company really wanted it safe, and they can't make it safe themselves, they can pay someone else to make it safe. If they aren't willing to do that, then nobody is obligated to do free work for them, because we don't require anyone else to do safety-critical work for free. Let's not forget, this isn't a scrappy startup struggling for a seed round, this is one of the world's largest corporations with billions of dollars in cash. If they want your labor, make them pay for it.
The discount Google is getting on bounties versus internal spend is easy to estimate:
# assumed to be $0.5mil USD or greater
A := What quantity of salaries-and-benefits and AI-dollars does Google spend on zero-day research?
# assumed to be greater than zero
B := How many full sandbox RCEs are they *hoping* to discover per year with that budget?
# $/RCE budgeted spend
C := A ÷ B
# $/bounty
D := $1000 USD
# % discount per bounty relative to in-house spend
E := (C - D) / C
While we lack the data to be sure, it is reasonable to estimate that they're getting a discount of 90% or better versus internal spend on this bounty payment, if one assumes that they do not have many sandbox RCEs left undiscovered. It's unclear whether that assumption holds, but with only a single researcher at an assumed $0.5mil/year (all-inclusive after pay, stock, and benefits) is enough to support the plausibility of that 90% figure, before accounting at market rates for their internal use of the house AIs.
So, the most likely case is that they're greedy and miserly, and hope we don't do the math. However I recognize that there are judgment calls to be made here. Either their internal spending finds hundreds of RCEs per year, or they're significantly discounting bounty payments versus their actual worth, or they're negligent in budgeting for RCE discovery at all, or they assign zero value to the security of the Chromium platform underpinning Edge, Electron, et al. All of these are bad in different ways; one hopes a competent tech reporter actually pursues this line of questioning with them!
> or they're negligent in budgeting for RCE discovery at all, or they assign zero value to the security of the Chromium platform underpinning Edge, Electron, et al
I generally agree, but a 3rd explanation is they figure that too generous a bounty will flood them with reports of minor issues making major ones harder to see (and costing time and money to verify that could be spent looking for security issues).
Having previously worked near a bounty program, I can confirm that they are regardless flooded with people fishing for bounties, even before AI, no matter how cheap the bounty may be — people will grift anything with the most pathetic skript kiddie attempts possible to try and pad their resume with a hit, and bounties that pay $0 are more valuable than pull requests that pay $0.
The problem is they are being flooded with both fake AND real disclosures. Imagine if they tried to pay out $250,000 or more per bug? Would the cost be worth it? Maybe, but shareholders may not be pleased... Unless they viewed it as insurance against it being more financially sound for the finder to sell the exploit on the gray or black market instead...
They should just multiply a base rate against the severity level. Say the base rate is ranged so low-severity stuff is $500-1K base but high-severity stuff is $10K base. That would net a researcher ~$88K for this specific bug (8.8 severity).
> How much do you think an organization like Google would spend on, for example, AI tokens or compute to detect this internally before it was found and exploited in the wild?
On average, probably not that much. What's the amortized cost of all testing, static analysis, and audit / code review, per "prevented potential bug"?
They're not going to stop underpaying security researchers just because security researchers decide to sell them to vuln brokers. Advocating for this is reckless.
> Ethical disclosure is a complicated topic, because researchers shouldn't hold bugs for ransom or demand high payment.
Why not? Capitalism requires they maximize their value. These profitable companies lay bare at the altar, so they should understand the requirements of their god.
There are plenty of people out there who find vulnerabilities and sell them to the highest bidder. Anyone is welcome to do it, including the researchers and hackers reporting them responsibly. There's no need to try and make a convoluted ethical justification. "I did this bad thing because you didn't pay me enough not to" doesn't work past the 6th grade.
The CVE associated with it (CVE-2026-85046) is already being exploited in the wild. If we put our thinking caps on, how much do you think this vulnerability is actually worth? How much do you think an organization like Google would spend on, for example, AI tokens or compute to detect this internally before it was found and exploited in the wild?
in the darkweb, due to crypto, a lot. there is where the $ is, whether it's stealing crypto directly or phishing developers.
Interesting question, and how much should a user pay Google to fix the vulnerability? I suppose the smallest unit of currency less than the amount of effort they'd have to put in to mitigate it. A fully market economy of bug fixing here is an interesting idea, certainly, but if I'm being honest I actually don't want to pay Google a thousand dollars to fix security issues. In the limit, what would happen is that I end up with the competitor browser Elgoog Emorhc which fixes security issues for free, and pays very little for them, which is the status quo.
In the world where security issues are paid for entirely at market rate, it would also be very important to not use browsers by poor groups because they would be unable to pay for security reports on the market and consequently the browsers would be less secure.
Interesting idea, for sure, but I don't think it lands in a place I want to go since I neither desire stochastic payments nor desire that all browsers should be from large corporations.
If the vulnerability is already being exploited in the wild --- as in, it's a vector people already know about and are tracking --- it's possibly not worth much at all. Vulnerability valuations depend heavily on the lifespan of the vulnerability; payments on black market are tranched (explicitly or less explicitly, as with "maintenance payments") based on whether they're patched.
Further: a vulnerability is probably not worth that much either, even if it's a hypercapable vulnerability, because the grey market buys full enablement kits, not vulnerability information. People making 6 figures on vulnerabilities are selling fully enabled full chain exploit systems, not just intelligence about a sandbox escape.
The value of future reports should also be a component though. By paying a low amount you discourage ethical bug bounty hackers from bothering to look for more exploits. If I think I'm only getting $1000 for a Chrome issue versus $100,000 for an Acme Co issue, I'll be spending my time looking for Acme Co issues.
Bug bounties are as much a way of attracting talent to even try to exploit your system as they are about the exploits themselves. If you lowball the bounties the talent goes elsewhere.
That's really informative but maybe a little overly capitalist-brained.
We shouldn't look to the black market as cost discovery for these vulnerabilities, most non-criminal researchers are not putting up an ask order and letting the black market compete with Google.
That's one of the points, yes, but the black market doesn't dictate the value of the exploit to Google.
A hardline bargaining position with Google would be more like "pay me what I want, or else I'll give it to all takers on the black market for maximum damage". That would be unethical and probably illegal to boot but it's a better definition of value than "1$ greater than max bid".
The value to Google - sure. But the market value of the exploit itself - the black market I think is a factor in that regardless of what Google offers.
The value of something is dictated by what _the market_ offers, and just because Google throws a lowball price because _they_ don't value it doesn't necessarily mean that the value of the exploit itself is as low as they dictate.
There will always be someone who would screw Google just for the love of the game, and if they got a better price from elsewhere, I don't see why _morality_ would really play that big of a role. It all comes down to incentives, and if Google doesn't incentivize doing the good thing enough, then someone _will_ incentivize them to do the bad thing just a bit more.
It sounds insultingly low, yeah. I'm trying to imagine why they would pay so little. The only two reasons I can think of are either (a) they were already aware of it and fixing it, and therefore the report didn't really change much, or (b) it requires an unusual configuration or otherwise rare opportunity to that makes it impractical to exploit most users. Really curious to see what the issue was whenever it gets made public.
> But at the same time, if someone submits a critical issue like this, it makes sense to pay them what the bug's actually worth.
I'd point out that part of the reason the grey and black market pays so well is because it is that type of market. You have to pay people extra to look past their morals and a risk premium against potential reputational and legal consequences.
Someone could sell it on the black market, sell it to Google, or just move on with their life and not sell it.
I don't know what this is worth on the black market, maybe I'd be scammed by even trying to sell it. Maybe I don't want to be a bad person. These are all things that go into the prices
Imagine the consideration for the Trump admin, should we pay this guy a million bucks for this attack that gets us into the command system of Iran, or would that be unethical. Of course they don't consider that at this time.
>researchers shouldn't hold bugs for ransom or demand high payment.
Hell no, the same level bugs at Google should be enthusiastically paid way more than from an undercapitalized startup, who actually needs the help more so. Should be orders of magnitude difference in relation to scale.
>it makes sense to pay them what the bug's actually worth.
Honest fair-dealing should come into play at least but there are some players who have struck it so rich they can now take enough pride to pay an additional premium just because they can, and their good human nature almost compels them ethically to do way more than the minimum.
Just apparently not at Google.
If a company has achieved financial success to a degree that they are no longer worried about complete failure for the foreseeable future, then it's only a matter of generosity vs Scrooge-like behavior.
What's missing from their overall business acumen if they can't even afford to project an image of generosity yet?
If they're not actively making a serious effort to pay the maximum they can well afford for bugs that are truly serious, there is a technical term for that. Chickenshit.
Makes you wonder how many hacks wouldn't have occurred if security researchers (and vulnerability disclosure) was actually rewarded proportional to the possible/potential damage said vulnerability may have otherwise caused.
It's insulting how poorly incentivised white hats are, just look at how much North Korea is raking in with their cyber shenanigans - current estimates put it at around $6.75 billion to date (over the past 10 years or so).
you're taking someone's word it's being exploited. It says right at the top of the report
> allowed a remote attacker to execute arbitrary code *inside the sandbox*
A bug in V8 leads to code execution in Chrome's web page process. It does not lead to execution in general. For that you need other exploits that escape the web page process. Those are not detailed here. This CVE is not a big deal. You're responding the poster's title, not the actual CVE
You've been on HN for 16 years and still comment the lowest brow possible comment on security vulnerability threads that the bounty isn't big enough. How many times do we need to have a top comment crying about the same thing? If you think its too little, sell the exploits you find for more.
Well, the implication (and I'm not saying this is right) is that to Google it's only worth $1k to have this brought to their attention by a white hat, versus finding out by exploitation.
Which means that they have zero concern from this incident about reputational damage to themselves or their browser. That's pretty good circumstantial evidence of a monopolistic practice, when you can safely assume that there's effectively no difference to your bottom line if your software is hacked.
But google is also a monopsony. There isn't anyone else the researcher can ethically sell it to. They just have to take whatever bounty google decides to pay.
I heard, on the podcast Darknet Diaries, that there are auctions for zero days in Argentina. This security researcher could probably have cleared a million dollars for a bug like that if they were unscrupulous. The bug bounty should absolutely be higher.
Normalising running arbitrary code delivered over the internet (in the form of JavaScript and WASM), as a necessary condition for accessing most web pages may not have been one of the best decisions we have made.
I remember noticing this shift in nerd culture. In the early 2000s, it was common for people to say on places like Slashdot that they don't trust JavaScript and run their browser with it off. In the early 2010s, I noticed HN commenters thought this was insane, tinfoil hat type thinking.
I say this as someone does NOT disable JS in my main browser (because like, I have a job), but also knows a fair bit about why Firefox inside Tails now restarts in some cases...
It's the classic thing. Across every gdmf metric, excluding with "true empathy", no one *gives a fuck* until it affects them, or someone within (1-3) degrees of separatation. And having broad empathy is generally a good way to get yourself labeled/astrocized: both about as obvious "compriate" and obvious "adversary".
I still run with u matrix though, and most third party requests can be limited, but I no longer have enough patience when a required page doesn't work - I'll just rely on ublock origin to work.
In fairness, in the early 2000s they were probably right. Early browser security model was a bit of a mess. The fact that this article is even talked about is a sign of how much better things are.
It's so ubiquitous and unavoidable at this point.. I was at a conference lecture in 2020 where someone was suggesting disabling JavaScript and I thought the same thing— how absurd. The times have really changed...
Running code by itself isn't that bad, it's the fact that browser developers have decided for some reason that this code needs to be as performant as possible, so, JIT.
I don't get it! The way JS is typically used, it doesn't even benefit from JIT all that much. Making ajax requests, doing stuff with strings, and moving DOM elements around doesn't need every CPU clock cycle to be used as optimally as possible. It's exceedingly rare for websites to actually be doing something that needs raw performance. And SPAs will be slow no matter what.
I suspect the people who agree to buy Jira & Confluence are not particularly heavy users of them. At least, that's the only explanation I can fathom for their continued sales.
I disagree about JIT performance not mattering. I enabled "Lockdown Mode" on iOS which disables the JIT for the mentioned security reasons, and it causes a very noticeable lagginess on many sites. Of course, the primary cause is the unnecessary JS monstrosities wasting CPU cycles. But practically speaking I can say that disabling the JIT results in a very subpar experience of many JS heavy pages.
That's largely because a lot of developers have made the devil's bargain of replacing standard web stuff with badly re-implemented JS versions of same. People did it because they could, but never considered if they should.
See most of the ecosystem around React, for reference. It's idiotic that things like URL management are done in Javascript. Or form controls. I guarantee that if we stopped doing this kind of stuff, JIT wouldn't matter.
To some extent this is just saying "developers will depend upon the performance given to them", and that's true, but it's also true that as soon as things like V8 and Node appeared, JS became ubiquitous. Pandora's container, if you will.
That's largely because a lot of developers have made the devil's bargain of replacing standard hardware and OS primitives with badly re-implemented C versions of same. People did it because they could, but never considered if they should.
See most of the ecosystem around modern systems software, for reference. It's idiotic that things like memory layout and bit-level hardware management are done in C abstractions. I guarantee that if we stopped doing this kind of stuff, compiler optimizations wouldn't matter.
To some extent this is just saying "developers will depend upon the performance given to them", and that's true, but it's also true that as soon as things like compilers and standard libraries appeared, C became ubiquitous. Pandora's container, if you will.
> It's idiotic that things like memory layout and bit-level hardware management are done in C abstractions. I guarantee that if we stopped doing this kind of stuff, compiler optimizations wouldn't matter.
Cute, but no, not even close to a good metaphor. The C example is abstracting away fundamental complexity in a new platform. The other is completely re-writing -- in duplicate and slightly broken -- what the platform gives you for free. There's nothing about implementing form controls or URL management in JS that is more abstract. It's just different; a downstream bad decision that branches off a long tree of other bad decisions.
The equivalent level of idiocy in a C-related metaphor would be...I dunno...if you decided that you didn't like the way that header files worked, and decided to keep the C compiler, but build an external header-file management system in Fortran [1] that calls the C compiler for you. Or even closer to the JS metaphor, you shipped a special C compiler that had an embedded interpreted language that only activated at compile time, and you then used that language to allow any user to fundamentally change the syntax of C.
(It hopefully shouldn't be lost on you that this exact approach to language features has been repeatedly tried in the javascript world, including right now, with package management. But see also: typescript, coffeescript before that, Dart, etc. Javascript is a mess, and history repeats itself with regularity about every 5 years.)
[1] ...and then you re-write that about sixty times, each time being slightly incompatible with the last, and all having different fundamental incompatibilities with C headers.
> See most of the ecosystem around React, for reference.
I've never used React myself, but what I've heard about it makes me question my own sanity. So are you going to tell me that instead of just updating the DOM tree directly I'm going to apply the changes to my data, then pass the entire model to the framework, which would then diff it with the previous version to get the changes back out, it would then call my functions that return components, and it would then diff the virtual DOM to find out what changed, and only then would it update the actual page? Why the fuck would anyone ever want that? What's so hard about simply changing the innerText or inserting elements or whatever?
Oh and now Google and Apple are insisting that this is the way to do UIs in native apps as well, with Compose and SwiftUI respectively.
The way the front end developer community seems to largely encourage learning top-down isn't helping either. I'll forever remember that one guy we made a small project with. He learned React but had no clue what "send a request" and "pass a parameter" means, and I had to explain him how to use XHR.
Sites are slow because with all that excess performance they do more tracking, instead of keeping the website as-is.
Because that's the only thing business managers can come up with in that situation. It's a misaligned goal of users vs businesses.
In my opinion the "user agent" behavior of browsers is long gone, because they're not acting on behalf of their users anymore. They're acting on behalf of businesses.
At this point SPA pretty much implies React. But even if you optimize everything the best you could and avoid any third-party runtime dependencies, it's still going to be significantly more work to make API requests and do client-side rendering vs just rendering HTML server-side.
I think the problem is that we've let JS engines become absurdly complex so there's no way to avoid them having really gross bugs.
That said, I think that the V8 team has done a fantastic job of securing their engine. Their heap sandbox feature is really inspiring! It's really wild that (as far as I can understand this issue) someone is able to bypass it.
(Posted from a memory safe browser - WebKit MiniBrowser compiled with Fil-C. Pretty sure this is safer than even V8 and the heap sandbox.)
We live in a world where my laptop is forced to waste tons of computational power on immensely bloated websites even with ad-block, with now even having to worry about agentic bullshit that I didn't ask for, and plenty of others apparently still think throwing computational cycles at cryptocurrency is good for anything.
Complaining about a relatively small performance price for Fil-C in that context honestly feels like that one famous newspaper photo of a smoking pregnant woman drinking a beer with a caption saying she's wbrried about the effects of the loud construction noises next door on her unborn child.
Except even that is wrong, because at least she had a point about the construction noises, while this is more of a "refusing to eat your vegetables" kind of situation.
This might oversell the agency that practicioners have.
Sandboxed zero-install delivery will outcompete anything with more frictionful installs.
It's probably not the right model for a pacemaker though.
Web/JS has been a double-edged sword for FOSS: sure, I can run a free OS, but if most of my "apps" happen to be JS that I can't practically control, then I have won a battle and lost a war.
I wish Haketilo [1] would have caught on more. There's so many free JavaScript apps but we're mostly just missing a way to actually control which version or derivative of the JavaScript is run.
There's also the problem of most free apps not doing a good job of providing license info and a link to source code, but this could be sidestepped by a trusted repository which provides license info itself.
Apple made it illegal to install an app - you have to use their store and pay a 30% extra tax, or do without, or make a web app. No surprise which option is most appealing.
Fortunately I disabled js by default. Unfortunately, it breaks about 30% of the web. Including nvd.nist.gov, which shows a completely blank page without js enabled, even though with js it’s just a simple page with only static content.
They just released a CVE for a garbage truck vulnerability where an attacker could brick the vehicle by exploiting the telemetry system these things now have preinstalled in factory.
> Type confusion in V8 in Google Chrome prior to 152.0.7977.82 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page.
So it was fixed in 152.0.7977.82 (before .83), if I read that right.
Just outta curiosity because I can't find it at a cursory look - what exactly would be the type (coersion?) that would allow v8 to execute arbitrary code? Is this like something in post data to nodejs that terminates early and is able to run exec or something, like unto a sql injection?
There’s a reason I use Firefox (Gecko). Also, Ladybird—another completely different web engine—is really promising. I spent five hours building it from source, having it take about 8 gigabytes of space, and it perfectly renders my own webpages and blogs.
I have a feeling someone’s going to make an open source browser using Ladybird’s engine before Ladybird has official binaries.
Not to downplay the severity (patch your browsers!), but there have been 5-10 actively-exploited V8 type confusion vulnerabilities in the last year. I'd be curious if this one blew up because it was the only one that was posted, or if it barely crossed some line in the collective consciousness this time around.
"Google has confirmed that an exploit exists in the wild but has not disclosed information about the threat actors, targeted organizations, or attack campaigns while the update is still rolling out."
If it's in the CISA known exploited vulnerabilities catalog, tell me if I'm wrong but I assume people don't go around exploiting million dollar 0-days in public just to fuck around safely in a chrome sandbox.
So maybe we're going to see another CVE for the sandbox escape soon?
Crypto mining would be one application. But also, combined with a sandbox escape would make it particularly devastating. Usually full control of a device takes at least two exploits given the layers of security present in OS and browser environments.
There's a risk that someone had been sitting on a sandbox escape that assumed having RCE inside the sandbox first, and so they'd been waiting for an RCE exactly like this one.
Those folks would not be disclosing their sandbox escape unless they were good guys.
That finally convinced me getting data using functions (accessors, getters, setters) is a good thing, even in C :) Just all that unnecesary if's are so annoing and killing performance...
It sounds technically possible to build a JIT where a verifier checks that the JIT-generated code is correctly pizlonated before allowing it to become executable. :)
WebKit's JS engine (JavaScriptCore) is super friendly to pointer capabilities. I did not have to change much to make it use the Fil-C GC instead of its own GC and to make it use a capability per JS object.
On the other hand, Chromium's JS engine (V8) does a bunch of crazy stuff with pointer encoding, so the best you could do there is probably a single arena for the whole JS heap.
Also, JavaScriptCore has a well-supported mode that involves not only zero JIT but a fully portable C++ interpreter. Not sure V8 has that.
It's because User Interaction is Required. CVSS 10 would be the case where everyone can be exploited without interaction.
Interestingly the 8.8 is more alert-worthy than the 9.8 and 10 cvss, because there is a need to be alerted of the current security risk, whereas with a cvss 2 vuln, there is nothing to be done by users, only admins.
As somebody who prefers to browse with JS off whenever possible, there's something absurd about the balance everyone takes for granted between (A) your personal safety against a devastating hack by malicious code and (B) surveillance advertising.
"Sorry, but to enter this shop you need to take one of the used syringes from that pile some dude delivers every day and poke yourself with it."
This seems irrelevant as the issue talks about being exploitable with a crafted HTML page, no mention of JS. If true, you would be able to be hit without js enabled.
It mentions a type confusion in V8. Is it possible to trigger that without JS enabled?
The "all chromium versions" part of the title is also misleading, most browser CVEs do not distinguish between "untested lower bound" vs "affects all" (even though it seems like it'd be trivial to bisect).
What exactly does "RCE inside sandbox" describe that goes beyond "the webpage can supply arbitrary JavaScript and the JavaScript engine executes it", but is still isolated from the system?
I think people would like to understand what the "sandbox" is here and what isolation does it provide, is it an unprivileged process? something chromium specific? a v8/JS thing? etc.
because with proper code exec you can trigger other bugs to escalate beyond the sandbox, whereas with JS you'd have to find a bug to escape from JS to native
can't get a proper ios/Android RCE with just JS code exec
Because Javascript theoretically can't just access files on disk. Control over the render would let you do that, if not for the process level sandbox, which constraints things like file access, system, calls, etc.
But the process is still more capable than the VM. The process can talk to other processes via IPC, for example.
That's why you don't go from "javascript -> computer is taken over", instead you go from "javascript -> renderer control -> computer is taken over".
Among other things, JavaScript in the browser has no way to even express "kill PID 1234 on the user's machine" or "list the contents of `C:\Users\Documents` and upload all of the files" or "spawn cmd.exe on the user's machine". How would you even do these things if you could run any JavaScript in the browser? You can't.
However, chrome.exe itself does because it's a native application, as is the sandboxed JavaScript interpreter inside of chrome.exe.
(This is a very oversimplified explanation but I think this is the disconnect people are having)
> JavaScript in the browser has no way to even express ... "list the contents of `C:\Users\Documents` and upload all of the files"
this is besides the point, but javascript has the file system api.
anyways to your broad point, i dont think this is convincing. What's the difference between not having an api vs having an api that is disabled (e.g. the syscall exists but is filtered). Either way you are not taking the action. RCE in the sandbox is an important step in the bigger exploit chain, but not because you can express things in the traditional syscalls inside the sandbox.
Memory isolation having one tab or account open on your bank and another on this page does not mean it could leak across the sandbox and steal bank account details but anything inside of your general page content can be lost
It means it can execute native code inside the sandbox, as opposed to Javascript. While still sandboxed, this lets it access some parts of the attack surface that JS would not have been able to, some of which may have other exploits that allow escaping the rest of the way.
Chrome runs webpages in individual sandbox processes with very low privileges, as a defense-in-depth strategy. It generally requires at least two exploits to actually affect a user--first, get RCE in a sandboxed process, then find a separate vulnerability that lets you escape the sandbox process entirely. For this bug to have actually been used in the wild, there was almost certainly a second bug as well.
I don't know why this is being downvoted. This is called malvertising and its one of the most significant vectors for exploiting a vulnerability like this. Its happened multiple times over the last two decades.
My read of Google's disclosure is that there is likely no known escape from the sandbox. I don't agree this would be reported this way just because "user action" like "using web browser" is required. Even if this individual CVE is correctly an 8.8 there would be a critical assessment of a known chain. The only reason there wouldn't be, would be if the other vulnerability is known to Google but has no patch yet.
This doesn't affect the score though, the reason there's 1.2 points less than the max is because there is a Required User Interaction. The user needs to visit a specific html page.
Even with the sandbox protection layer, the rest of the parameters are maxed out.
$1k for this vuln is laughable. If the researcher wrote an exploit as the nday exploit devs did and sold it in the gray market they would of got significantly more.
Firefox absolutely does not have a better security track record than Chromium browsers and on top of it you’re recommending an extension as a security measure oh my god man this comment needs to be flagged dead
Despite what people are saying here, chrome has a really excellent track record. Nobody is perfect. Switching just because chrome got exploited one time will likely result in you switching to something worse.
I don’t disagree, two or more things can be true at once.
That said I still use Firefox for other reasons.
I simply don’t trust google, I don’t trust Mozilla either but I do trust them more than Google and you do kinda have to have a browser to function in the modern world.
Let's take a moment to talk about the monetary value of this vulnerability.
According to the Chrome release page (https://chromereleases.googleblog.com/2026/09/stable-channel...), Google paid a researcher $1000 for ethically reporting this.
The CVE associated with it (CVE-2026-85046) is already being exploited in the wild. If we put our thinking caps on, how much do you think this vulnerability is actually worth? How much do you think an organization like Google would spend on, for example, AI tokens or compute to detect this internally before it was found and exploited in the wild?
Ethical disclosure is a complicated topic, because researchers shouldn't hold bugs for ransom or demand high payment. But at the same time, if someone submits a critical issue like this, it makes sense to pay them what the bug's actually worth. Why should a researcher be effectively penalized for responsibly telling a vendor instead of selling the bug to a "research firm" or three-letter agency?
It's one thing if you're an open source project maintainer just trying to put something out to the community. The math is a lot different if you're Google.
While I agree 1000 is hilariously low for this, worth is hard to quantify. Do you pay what it could theoretically cost your company? the amount the top bidding bad actor would be willing to pay?
ideally, an auction and the vendor or a government can bid against malicious actors (which can also be a government). hard to set up though.
it seems unlikely google's lawyers would go for this
well that's why setting it up is hard, because you would want to do it in a way that what they want doesn't matter.
Maybe some code is so important and heavily trafficked it becomes a public works project, and various legs can bid for pieces of the project, line how all infrastructure works.
What kind of auction would you like to run?
Remember that you can sell the same vulnerability to multiple people: it's software you can copy.
Maybe needs a Good-Guy-Buy-It-Now w/instant delivery at a fair price. (OK that’s kind of a threat—you’re running an auction and you have the price the corp has to pay to avoid the auction ending.)
$1k is so dumb and the fact we’re discussing auctions is proof (hello, Sundar, what you doing over there?).
Guess this will change after the next e.g. nationwide hospital ransomware by a hacker who publicly laments bounty rates, if the news cycle accommodates the story long enough.
You let the market decide. Google could purchase the bugs on the same market blackhats do.
In the past I would have thought this would incentivize finding bugs that might never be found. However it is now clear that all bugs that can be found will be found. So this makes a ton of sense.
> In the past I would have thought this would incentivize finding bugs that might never be found.
Isn't that a good thing?
> However it is now clear that all bugs that can be found will be found. So this makes a ton of sense.
If Google can find all the bugs nowadays, presumably with AI, why still pay a bug bounty? At least by this logic, bug bounties make less sense now.
Sure they make sense — you need some incentive to drive the price to zero.
Because there’s still a sizable group of people who see $1,000 from Google as more than $1,000.
Even a resume item.
Google directly competes with the grey market for vulnerabilities. They are competitive in a bunch of different directions:
* They pay for vulnerabilities without reliable exploits (more for vulnerabilities that are demonstrably reliable).
* They don't require you to actually build a reliable exploit chain.
* They pay up front, not in tranches.
* They work with essentially all comers, unlike the grey market, where you're generally subcontracting to sell your first few.
They pay in plain old money, too. On the market your counterparty will be a criminal who is trying to scam you every step of the way.
Not so much, the grey market is pretty well structured.
Is there anywhere I could read more about this?
Sound very interesting!
Blackhat markets will always be able to pay better. Selling to Google though you aren't chancing jail time.
> Blackhat markets will always be able to pay better.
... than Google?
> Selling to Google though you aren't chancing jail time.
Why would you go to jail for selling a vulnerability? It's free speech.
"Aiding and Abetting" crime is also a crime. Free speech has nothing to do with it.
Has anyone actually been convicted of abetting a crime by selling a vulnerability, by itself, not conspiring with the buyer to commit a crime using said vulnerability? Not as far as I can see. It would be absurd to jail someone for accurately describing a bug.
"this vulnerability is being sold for research purposes only and must never be used outside of a tightly controlled research sandbox"
Telling someone the steps to rob a bank world probably catch you some charges, I'm assuming.
No, it wouldn't.
Well, someone did decide to tell google about this in exchange for a thousand dollars (albeit unclear how much the money was the motivator). Doesn't that mean the market did decide in google's favour?
Someone decided to tell Google about this in exchange for an unknown amount of money, chosen unilaterally by Google at a later date, at which point the market value of the vulnerability is $0.
There's no way money is the motivator.
Money is not the only coin to pay someone in.
we really do not want to engineer a system in which using bugs to make money is considered economically legitimate activity. It is still crime. The main reason to report bugs and get the bounties for doing so is still because it makes the world safer and healthier. The money is there to make is to incentivize the work of finding and reporting them -- not to outbid the bad actors.
Companies sometimes reward their employees with important bug fixes. When I worked on a big dev team, we'd even decide what were the most important fixes and give people a special 5k bonus or something.
But they weren't security issues necessarily. I never thought about it, fixing a huge performance issue is big. A security fix that gets caught early makes no noise so you just don't know how important it would have been. We also once had a really terrible bug that lead to lots of customers getting effectively attacked.
Finding bugs is hardly a crime, selling them even isn't.
Now exploiting them? Yes that's a crime.
"Crime" is very flexible term. One country's criminal is another country hero. Maybe the author would sell the vulnerability to an organization making exploits for government use.
"Safety" is also a relative thing, when the world is safer for one party, it is usually worse for another.
Having secure browsers, encryption etc. actually clearly benefits the world. No “but think about the children/terrorists” please.
> we really do not want to engineer a system in which using bugs to make money is considered economically legitimate activity. It is still crime.
"Making money from bugs" is not solely a black-market activity. There are plenty of grey and even white hat activities in this market.
> The main reason to report bugs and get the bounties for doing so is still because it makes the world safer and healthier.
Yeah let's see how this plays out, paying people less than their time is worth for RCEs.
> using bugs to make money
Aka security research.
It's one thing to hold something for ransom ("give me $5M or I release the 0day"). It's another to sell a valuable piece of information ("give me $5M if you want the 0day"). As long as you're only offering the bug to the company who would be impacted by its release, there's nothing unethical about asking for payment.
Maybe you think that, ethically, all bugs should be reported, regardless of payment, because it prevents harm. Well a lot of things prevent harm that we don't all take it upon ourselves to do voluntarily. Should everyone do all safety-related work for free? If we don't want to do it for free, should we not do safety work at all?
If the company really wanted it safe, and they can't make it safe themselves, they can pay someone else to make it safe. If they aren't willing to do that, then nobody is obligated to do free work for them, because we don't require anyone else to do safety-critical work for free. Let's not forget, this isn't a scrappy startup struggling for a seed round, this is one of the world's largest corporations with billions of dollars in cash. If they want your labor, make them pay for it.
>Well a lot of things prevent harm that we don't all take it upon ourselves to do voluntarily. Should everyone do all safety-related work for free?
Thanks for putting it like that, it changed my opinion on the subject.
If it's normal to expect people to be compensated for other security work, it implies it should also be normal to compensate security researches.
> using bugs to make money [is a crime]
No it’s not lol
They would be broke quick.
The discount Google is getting on bounties versus internal spend is easy to estimate:
While we lack the data to be sure, it is reasonable to estimate that they're getting a discount of 90% or better versus internal spend on this bounty payment, if one assumes that they do not have many sandbox RCEs left undiscovered. It's unclear whether that assumption holds, but with only a single researcher at an assumed $0.5mil/year (all-inclusive after pay, stock, and benefits) is enough to support the plausibility of that 90% figure, before accounting at market rates for their internal use of the house AIs.
So, the most likely case is that they're greedy and miserly, and hope we don't do the math. However I recognize that there are judgment calls to be made here. Either their internal spending finds hundreds of RCEs per year, or they're significantly discounting bounty payments versus their actual worth, or they're negligent in budgeting for RCE discovery at all, or they assign zero value to the security of the Chromium platform underpinning Edge, Electron, et al. All of these are bad in different ways; one hopes a competent tech reporter actually pursues this line of questioning with them!
> or they're negligent in budgeting for RCE discovery at all, or they assign zero value to the security of the Chromium platform underpinning Edge, Electron, et al
I generally agree, but a 3rd explanation is they figure that too generous a bounty will flood them with reports of minor issues making major ones harder to see (and costing time and money to verify that could be spent looking for security issues).
Having previously worked near a bounty program, I can confirm that they are regardless flooded with people fishing for bounties, even before AI, no matter how cheap the bounty may be — people will grift anything with the most pathetic skript kiddie attempts possible to try and pad their resume with a hit, and bounties that pay $0 are more valuable than pull requests that pay $0.
The problem is they are being flooded with both fake AND real disclosures. Imagine if they tried to pay out $250,000 or more per bug? Would the cost be worth it? Maybe, but shareholders may not be pleased... Unless they viewed it as insurance against it being more financially sound for the finder to sell the exploit on the gray or black market instead...
They should just multiply a base rate against the severity level. Say the base rate is ranged so low-severity stuff is $500-1K base but high-severity stuff is $10K base. That would net a researcher ~$88K for this specific bug (8.8 severity).
CVE severity is a terrible way to do this. If you follow the cybersecurity space you should know why.
That would create a perverse incentive to inflate the severity levels even more than they already are
Pre-flood, they didn’t pay more did they?
> viewed it as insurance
Of course. Beyond the ethics, the social obligation, sleeping well at night by compensating hardworking people fairly.
“We can’t pay more or we’d have to hire more human reviewers” should never be a massive company’s line of thinking.
https://bughunters.google.com/about/key-stats
Total rewards given $81,933,423
it's such a drop in the bucket, it wouldn't make any difference
> How much do you think an organization like Google would spend on, for example, AI tokens or compute to detect this internally before it was found and exploited in the wild?
On average, probably not that much. What's the amortized cost of all testing, static analysis, and audit / code review, per "prevented potential bug"?
this is why again, researchers should just honestly sell these to vuln brokers instead of donating them to trillion dollar companies for nothing.
nothing will change until big tech can no longer rip off security researchers
But my “Google paid me” on my resume!
They're not going to stop underpaying security researchers just because security researchers decide to sell them to vuln brokers. Advocating for this is reckless.
> Ethical disclosure is a complicated topic, because researchers shouldn't hold bugs for ransom or demand high payment.
Why not? Capitalism requires they maximize their value. These profitable companies lay bare at the altar, so they should understand the requirements of their god.
There are plenty of people out there who find vulnerabilities and sell them to the highest bidder. Anyone is welcome to do it, including the researchers and hackers reporting them responsibly. There's no need to try and make a convoluted ethical justification. "I did this bad thing because you didn't pay me enough not to" doesn't work past the 6th grade.
The CVE associated with it (CVE-2026-85046) is already being exploited in the wild. If we put our thinking caps on, how much do you think this vulnerability is actually worth? How much do you think an organization like Google would spend on, for example, AI tokens or compute to detect this internally before it was found and exploited in the wild?
in the darkweb, due to crypto, a lot. there is where the $ is, whether it's stealing crypto directly or phishing developers.
If this would have included a full RCE chain with Sandbox escape Google would have paid significantly more.
Having just a Sandbox RCE is neat, I've got some on my laptop currently, but it's just a piece of the puzzle.
Interesting question, and how much should a user pay Google to fix the vulnerability? I suppose the smallest unit of currency less than the amount of effort they'd have to put in to mitigate it. A fully market economy of bug fixing here is an interesting idea, certainly, but if I'm being honest I actually don't want to pay Google a thousand dollars to fix security issues. In the limit, what would happen is that I end up with the competitor browser Elgoog Emorhc which fixes security issues for free, and pays very little for them, which is the status quo.
In the world where security issues are paid for entirely at market rate, it would also be very important to not use browsers by poor groups because they would be unable to pay for security reports on the market and consequently the browsers would be less secure.
Interesting idea, for sure, but I don't think it lands in a place I want to go since I neither desire stochastic payments nor desire that all browsers should be from large corporations.
If the vulnerability is already being exploited in the wild --- as in, it's a vector people already know about and are tracking --- it's possibly not worth much at all. Vulnerability valuations depend heavily on the lifespan of the vulnerability; payments on black market are tranched (explicitly or less explicitly, as with "maintenance payments") based on whether they're patched.
Further: a vulnerability is probably not worth that much either, even if it's a hypercapable vulnerability, because the grey market buys full enablement kits, not vulnerability information. People making 6 figures on vulnerabilities are selling fully enabled full chain exploit systems, not just intelligence about a sandbox escape.
How much money is lost by consumers/businesses for every hour the vulnerability is exploited in the wild with no patch?
That’s not how things are valued. That’s moreso how the absence of something is valued.
Go without air for a few minutes and you’ll die, and yet they give the stuff away for free.
The value of the report is dependent on the scarcity of the knowledge. If anybody can report it, the bid goes down.
There is a theta decay component. The zero day is highly valuable until known; once known, its value rapidly declines to zero.
The value of future reports should also be a component though. By paying a low amount you discourage ethical bug bounty hackers from bothering to look for more exploits. If I think I'm only getting $1000 for a Chrome issue versus $100,000 for an Acme Co issue, I'll be spending my time looking for Acme Co issues.
Bug bounties are as much a way of attracting talent to even try to exploit your system as they are about the exploits themselves. If you lowball the bounties the talent goes elsewhere.
That's really informative but maybe a little overly capitalist-brained.
We shouldn't look to the black market as cost discovery for these vulnerabilities, most non-criminal researchers are not putting up an ask order and letting the black market compete with Google.
> We shouldn't look to the black market as cost discovery for these vulnerabilities
We absolutely should. One of the points of bug bounties is to discourage people from selling to the black market.
That's one of the points, yes, but the black market doesn't dictate the value of the exploit to Google.
A hardline bargaining position with Google would be more like "pay me what I want, or else I'll give it to all takers on the black market for maximum damage". That would be unethical and probably illegal to boot but it's a better definition of value than "1$ greater than max bid".
The value to Google - sure. But the market value of the exploit itself - the black market I think is a factor in that regardless of what Google offers.
The value of something is dictated by what _the market_ offers, and just because Google throws a lowball price because _they_ don't value it doesn't necessarily mean that the value of the exploit itself is as low as they dictate.
There will always be someone who would screw Google just for the love of the game, and if they got a better price from elsewhere, I don't see why _morality_ would really play that big of a role. It all comes down to incentives, and if Google doesn't incentivize doing the good thing enough, then someone _will_ incentivize them to do the bad thing just a bit more.
I was under the impression that the three letter agencies and contractors bought vulnerabilities?
Seems like it was worth $1000 to the researcher in question.
It sounds insultingly low, yeah. I'm trying to imagine why they would pay so little. The only two reasons I can think of are either (a) they were already aware of it and fixing it, and therefore the report didn't really change much, or (b) it requires an unusual configuration or otherwise rare opportunity to that makes it impractical to exploit most users. Really curious to see what the issue was whenever it gets made public.
(c) there are so many undiscovered vulnerabilities that it doesn't make sense for them to offer a decent payout
> But at the same time, if someone submits a critical issue like this, it makes sense to pay them what the bug's actually worth.
I'd point out that part of the reason the grey and black market pays so well is because it is that type of market. You have to pay people extra to look past their morals and a risk premium against potential reputational and legal consequences.
That said, the gap is probably not just that.
It seems like by definition it is.
Someone could sell it on the black market, sell it to Google, or just move on with their life and not sell it.
I don't know what this is worth on the black market, maybe I'd be scammed by even trying to sell it. Maybe I don't want to be a bad person. These are all things that go into the prices
"because researchers shouldn't hold bugs for ransom or demand high payment" Maybe they should now, not like anyone else cares about ethics anyway.
Imagine the consideration for the Trump admin, should we pay this guy a million bucks for this attack that gets us into the command system of Iran, or would that be unethical. Of course they don't consider that at this time.
If you really explore the concept of worth, Google "engineers" are grossly overpaid, otherwise they would have found this themselves already.
How many PMs are making more than bug bounties to fetch coffee and bagels?
Their priorities are all out of order.
>researchers shouldn't hold bugs for ransom or demand high payment.
Hell no, the same level bugs at Google should be enthusiastically paid way more than from an undercapitalized startup, who actually needs the help more so. Should be orders of magnitude difference in relation to scale.
>it makes sense to pay them what the bug's actually worth.
Honest fair-dealing should come into play at least but there are some players who have struck it so rich they can now take enough pride to pay an additional premium just because they can, and their good human nature almost compels them ethically to do way more than the minimum.
Just apparently not at Google.
If a company has achieved financial success to a degree that they are no longer worried about complete failure for the foreseeable future, then it's only a matter of generosity vs Scrooge-like behavior.
What's missing from their overall business acumen if they can't even afford to project an image of generosity yet?
If they're not actively making a serious effort to pay the maximum they can well afford for bugs that are truly serious, there is a technical term for that. Chickenshit.
People are free to pool their money and offer higher bounties.
Makes you wonder how many hacks wouldn't have occurred if security researchers (and vulnerability disclosure) was actually rewarded proportional to the possible/potential damage said vulnerability may have otherwise caused.
It's insulting how poorly incentivised white hats are, just look at how much North Korea is raking in with their cyber shenanigans - current estimates put it at around $6.75 billion to date (over the past 10 years or so).
> Ethical disclosure is a complicated topic, because researchers shouldn't hold bugs for ransom or demand high payment.
I mean, why not?
you're taking someone's word it's being exploited. It says right at the top of the report
> allowed a remote attacker to execute arbitrary code *inside the sandbox*
A bug in V8 leads to code execution in Chrome's web page process. It does not lead to execution in general. For that you need other exploits that escape the web page process. Those are not detailed here. This CVE is not a big deal. You're responding the poster's title, not the actual CVE
> I chained this bug with an n-day sandbox escape and flagged the v8CTF.
https://serotav.github.io/Writeups/v8/when-sorting-leads-to-...
You've been on HN for 16 years and still comment the lowest brow possible comment on security vulnerability threads that the bounty isn't big enough. How many times do we need to have a top comment crying about the same thing? If you think its too little, sell the exploits you find for more.
Well, the implication (and I'm not saying this is right) is that to Google it's only worth $1k to have this brought to their attention by a white hat, versus finding out by exploitation.
Which means that they have zero concern from this incident about reputational damage to themselves or their browser. That's pretty good circumstantial evidence of a monopolistic practice, when you can safely assume that there's effectively no difference to your bottom line if your software is hacked.
But google is also a monopsony. There isn't anyone else the researcher can ethically sell it to. They just have to take whatever bounty google decides to pay.
I heard, on the podcast Darknet Diaries, that there are auctions for zero days in Argentina. This security researcher could probably have cleared a million dollars for a bug like that if they were unscrupulous. The bug bounty should absolutely be higher.
Normalising running arbitrary code delivered over the internet (in the form of JavaScript and WASM), as a necessary condition for accessing most web pages may not have been one of the best decisions we have made.
In the future we can ask that your JaveScript and Wasm comes with a proof of being benign.
Prior art: the evil bit
https://datatracker.ietf.org/doc/html/rfc3514
I remember noticing this shift in nerd culture. In the early 2000s, it was common for people to say on places like Slashdot that they don't trust JavaScript and run their browser with it off. In the early 2010s, I noticed HN commenters thought this was insane, tinfoil hat type thinking.
It became insane because nothing bloody worked without Javascript some time in the early 2010s.
Like cellphones, javascript became necessary if you want to use webmail, access your bank's website, or whatever.
I say this as someone does NOT disable JS in my main browser (because like, I have a job), but also knows a fair bit about why Firefox inside Tails now restarts in some cases...
It's the classic thing. Across every gdmf metric, excluding with "true empathy", no one *gives a fuck* until it affects them, or someone within (1-3) degrees of separatation. And having broad empathy is generally a good way to get yourself labeled/astrocized: both about as obvious "compriate" and obvious "adversary".
Is compriate a typo, a neologism? I could not find a definition.
I still run with u matrix though, and most third party requests can be limited, but I no longer have enough patience when a required page doesn't work - I'll just rely on ublock origin to work.
I still do "random" browsing in FF with NoScript, that said, I'll acknowledge the frequency of updates of Chrome,etc and years of hardening.
It's not the Bonzi-buddy and driveby-installed IE toolbars wild west of the early 00s.
The browsers on the computers at work show that it is very much still the driveby tool-bar install days.
In fairness, in the early 2000s they were probably right. Early browser security model was a bit of a mess. The fact that this article is even talked about is a sign of how much better things are.
Plus add in Flash and Java applets.
It's so ubiquitous and unavoidable at this point.. I was at a conference lecture in 2020 where someone was suggesting disabling JavaScript and I thought the same thing— how absurd. The times have really changed...
V8 as a runtime goes far deeper than just webpages.
Running code by itself isn't that bad, it's the fact that browser developers have decided for some reason that this code needs to be as performant as possible, so, JIT.
I don't get it! The way JS is typically used, it doesn't even benefit from JIT all that much. Making ajax requests, doing stuff with strings, and moving DOM elements around doesn't need every CPU clock cycle to be used as optimally as possible. It's exceedingly rare for websites to actually be doing something that needs raw performance. And SPAs will be slow no matter what.
Agree. Chrome should just disable JIT by default and boom many website owner will start to optimize their website.
jira and confluence come to mind...
I suspect the people who agree to buy Jira & Confluence are not particularly heavy users of them. At least, that's the only explanation I can fathom for their continued sales.
Is it their app’s features that are slow, or the analytics bolted on top?
Both. And all the dependencies of both are slow. And the dependencies of those are slow, too.
I disagree about JIT performance not mattering. I enabled "Lockdown Mode" on iOS which disables the JIT for the mentioned security reasons, and it causes a very noticeable lagginess on many sites. Of course, the primary cause is the unnecessary JS monstrosities wasting CPU cycles. But practically speaking I can say that disabling the JIT results in a very subpar experience of many JS heavy pages.
It will also increase power consumption because your CPU has to do more work to run the same code.
That's largely because a lot of developers have made the devil's bargain of replacing standard web stuff with badly re-implemented JS versions of same. People did it because they could, but never considered if they should.
See most of the ecosystem around React, for reference. It's idiotic that things like URL management are done in Javascript. Or form controls. I guarantee that if we stopped doing this kind of stuff, JIT wouldn't matter.
To some extent this is just saying "developers will depend upon the performance given to them", and that's true, but it's also true that as soon as things like V8 and Node appeared, JS became ubiquitous. Pandora's container, if you will.
That's largely because a lot of developers have made the devil's bargain of replacing standard hardware and OS primitives with badly re-implemented C versions of same. People did it because they could, but never considered if they should.
See most of the ecosystem around modern systems software, for reference. It's idiotic that things like memory layout and bit-level hardware management are done in C abstractions. I guarantee that if we stopped doing this kind of stuff, compiler optimizations wouldn't matter.
To some extent this is just saying "developers will depend upon the performance given to them", and that's true, but it's also true that as soon as things like compilers and standard libraries appeared, C became ubiquitous. Pandora's container, if you will.
> It's idiotic that things like memory layout and bit-level hardware management are done in C abstractions. I guarantee that if we stopped doing this kind of stuff, compiler optimizations wouldn't matter.
Cute, but no, not even close to a good metaphor. The C example is abstracting away fundamental complexity in a new platform. The other is completely re-writing -- in duplicate and slightly broken -- what the platform gives you for free. There's nothing about implementing form controls or URL management in JS that is more abstract. It's just different; a downstream bad decision that branches off a long tree of other bad decisions.
The equivalent level of idiocy in a C-related metaphor would be...I dunno...if you decided that you didn't like the way that header files worked, and decided to keep the C compiler, but build an external header-file management system in Fortran [1] that calls the C compiler for you. Or even closer to the JS metaphor, you shipped a special C compiler that had an embedded interpreted language that only activated at compile time, and you then used that language to allow any user to fundamentally change the syntax of C.
(It hopefully shouldn't be lost on you that this exact approach to language features has been repeatedly tried in the javascript world, including right now, with package management. But see also: typescript, coffeescript before that, Dart, etc. Javascript is a mess, and history repeats itself with regularity about every 5 years.)
[1] ...and then you re-write that about sixty times, each time being slightly incompatible with the last, and all having different fundamental incompatibilities with C headers.
> See most of the ecosystem around React, for reference.
I've never used React myself, but what I've heard about it makes me question my own sanity. So are you going to tell me that instead of just updating the DOM tree directly I'm going to apply the changes to my data, then pass the entire model to the framework, which would then diff it with the previous version to get the changes back out, it would then call my functions that return components, and it would then diff the virtual DOM to find out what changed, and only then would it update the actual page? Why the fuck would anyone ever want that? What's so hard about simply changing the innerText or inserting elements or whatever?
Oh and now Google and Apple are insisting that this is the way to do UIs in native apps as well, with Compose and SwiftUI respectively.
The way the front end developer community seems to largely encourage learning top-down isn't helping either. I'll forever remember that one guy we made a small project with. He learned React but had no clue what "send a request" and "pass a parameter" means, and I had to explain him how to use XHR.
you are talking about the effect, not the cause.
Sites are slow because with all that excess performance they do more tracking, instead of keeping the website as-is.
Because that's the only thing business managers can come up with in that situation. It's a misaligned goal of users vs businesses.
In my opinion the "user agent" behavior of browsers is long gone, because they're not acting on behalf of their users anymore. They're acting on behalf of businesses.
> SPAs will be slow no matter what.
Uh…no?
You’re presumably talking about specific terrible prebuilt frameworks - not someone building a nice vanilla SPA.
At this point SPA pretty much implies React. But even if you optimize everything the best you could and avoid any third-party runtime dependencies, it's still going to be significantly more work to make API requests and do client-side rendering vs just rendering HTML server-side.
I think the problem is that we've let JS engines become absurdly complex so there's no way to avoid them having really gross bugs.
That said, I think that the V8 team has done a fantastic job of securing their engine. Their heap sandbox feature is really inspiring! It's really wild that (as far as I can understand this issue) someone is able to bypass it.
(Posted from a memory safe browser - WebKit MiniBrowser compiled with Fil-C. Pretty sure this is safer than even V8 and the heap sandbox.)
> Posted from a memory safe browser - WebKit MiniBrowser compiled with Fil-C. Pretty sure this is safer than even V8 and the heap sandbox.
It's easy to be safer, as long as performance can be sacrificed for it.
We live in a world where my laptop is forced to waste tons of computational power on immensely bloated websites even with ad-block, with now even having to worry about agentic bullshit that I didn't ask for, and plenty of others apparently still think throwing computational cycles at cryptocurrency is good for anything.
Complaining about a relatively small performance price for Fil-C in that context honestly feels like that one famous newspaper photo of a smoking pregnant woman drinking a beer with a caption saying she's wbrried about the effects of the loud construction noises next door on her unborn child.
Except even that is wrong, because at least she had a point about the construction noises, while this is more of a "refusing to eat your vegetables" kind of situation.
In Chromium you can turn off V8's JIT compiler for this reason. You can even opt in again for sites you trust that need the additional performance.
> decision we have made
This might oversell the agency that practicioners have.
Sandboxed zero-install delivery will outcompete anything with more frictionful installs.
It's probably not the right model for a pacemaker though.
Web/JS has been a double-edged sword for FOSS: sure, I can run a free OS, but if most of my "apps" happen to be JS that I can't practically control, then I have won a battle and lost a war.
I wish Haketilo [1] would have caught on more. There's so many free JavaScript apps but we're mostly just missing a way to actually control which version or derivative of the JavaScript is run.
There's also the problem of most free apps not doing a good job of providing license info and a link to source code, but this could be sidestepped by a trusted repository which provides license info itself.
[1] https://haketilo.koszko.org/
Apple made it illegal to install an app - you have to use their store and pay a 30% extra tax, or do without, or make a web app. No surprise which option is most appealing.
Does that somehow also explain why many (most?) desktop users survive with just a browser?
To be clear, I'm not saying it doesn't. I'm saying I don't understand.
> Type confusion in V8
Fortunately I disabled js by default. Unfortunately, it breaks about 30% of the web. Including nvd.nist.gov, which shows a completely blank page without js enabled, even though with js it’s just a simple page with only static content.
I’m so tired. I think I’m just going to get a job as a garbage man and cancel my internet.
There's been a Chrome CVE like every week ever since it came out.
They just released a CVE for a garbage truck vulnerability where an attacker could brick the vehicle by exploiting the telemetry system these things now have preinstalled in factory.
Sounds like much needed downtime for the person slinging the garbage then.
Brave is beating GrapheneOS on update timeliness:
https://github.com/GrapheneOS/Vanadium/releases
https://github.com/brave/brave-browser/releases
Only if you use Nightly wait maybe not.
The release version just now updated to 152.0.7977.83 which has the fix.
I upgraded Vivaldi, which is reporting 152.0.7977.112
Is graphene even affected? JIT is disabled in default configurations.
This issue is already fixed in Google Chrome (152.0.7977.83)
TFA says
> Type confusion in V8 in Google Chrome prior to 152.0.7977.82 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page.
So it was fixed in 152.0.7977.82 (before .83), if I read that right.
You read that right. From the article:
"Affected products: ... Up to (excluding) 152.0.7977.82"
.82 is fixed.
Just outta curiosity because I can't find it at a cursory look - what exactly would be the type (coersion?) that would allow v8 to execute arbitrary code? Is this like something in post data to nodejs that terminates early and is able to run exec or something, like unto a sql injection?
Isn't this exactly why there is a sandbox? What can the RCE actually do or obtain within the sandbox?
Yes, it says right in the CVE
> allowed a remote attacker to execute arbitrary code *inside the sandbox*
So basically, Edge, Brave and any other browser built on Chromium. Nice.
Monocultures are great!
There’s a reason I use Firefox (Gecko). Also, Ladybird—another completely different web engine—is really promising. I spent five hours building it from source, having it take about 8 gigabytes of space, and it perfectly renders my own webpages and blogs.
I have a feeling someone’s going to make an open source browser using Ladybird’s engine before Ladybird has official binaries.
Not to downplay the severity (patch your browsers!), but there have been 5-10 actively-exploited V8 type confusion vulnerabilities in the last year. I'd be curious if this one blew up because it was the only one that was posted, or if it barely crossed some line in the collective consciousness this time around.
Does anybody have a source for the "actively exploited" part of the HN title?
"Google has confirmed that an exploit exists in the wild but has not disclosed information about the threat actors, targeted organizations, or attack campaigns while the update is still rolling out."
by nature of being in the "known exploited vulnerabilities catalog" (https://www.cisa.gov/known-exploited-vulnerabilities-catalog...)
"CISA maintains the authoritative source of vulnerabilities that have been exploited in the wild."
This line, I think? >This CVE is in CISA's Known Exploited Vulnerabilities Catalog
For what is this exploited in the wild when it doesn't include a sandbox escape?
Is this chained with n-days?
If it's in the CISA known exploited vulnerabilities catalog, tell me if I'm wrong but I assume people don't go around exploiting million dollar 0-days in public just to fuck around safely in a chrome sandbox.
So maybe we're going to see another CVE for the sandbox escape soon?
Crypto mining would be one application. But also, combined with a sandbox escape would make it particularly devastating. Usually full control of a device takes at least two exploits given the layers of security present in OS and browser environments.
There's a risk that someone had been sitting on a sandbox escape that assumed having RCE inside the sandbox first, and so they'd been waiting for an RCE exactly like this one.
Those folks would not be disclosing their sandbox escape unless they were good guys.
(Posted with a memory safe WebKit, Fil-C FTW)
struct MessageBuffer
{
};
That finally convinced me getting data using functions (accessors, getters, setters) is a good thing, even in C :) Just all that unnecesary if's are so annoing and killing performance...
Sounds wild.
(Posted from memory safe WebKit; i.e. WebKit compiled with filcc and all of WebKit's dependencies compiled with filcc.)
For it to be memory safe, do you have to disable the JIT?
Yeah
It sounds technically possible to build a JIT where a verifier checks that the JIT-generated code is correctly pizlonated before allowing it to become executable. :)
Yes
I have a new tech called SaRCAsm, which is a memory-safe assembler. So the next step is a "Sarcastic JIT" :-)
I think it makes more sense to verify that the jit is correct than to verify that it's output is correct at runtime.
Nah
It's damn near impossible to verify that the JIT is correct.
But it is possible to verify at runtime that the code that the JIT emitted obeys some memory safety law.
(V8's heap sandbox is an example of this; a sarcastic JIT would be an arguably stronger example of this.)
Wait, you have that working? What's the lowest friction to run it? Like, VM or docker container or...
VM
https://fil-c.org/pizlix
Then build WebKit using do_cmake_yolo_simpler.sh in projects/webkitgtk-2.44.3
It's still pretty rough, but works more than well enough to post on HN. My regression test is to post on X. That works too
Sweet, thanks. I guess running in a VM is also a bonus protective layer:)
lol yeah
Pls file bugs if you encounter issues.
Also, fair warning, it's hella slow right now on JS-heavy websites (like X). It barely works.
But we can fix that with some effort, I think
Is that just the MiniBrowser?! I have to say I can't imagine daily driving that if so. Why WebKit over a Chromium-based (and more featureful) browser?
I'll port Epiphany eventually.
WebKit's JS engine (JavaScriptCore) is super friendly to pointer capabilities. I did not have to change much to make it use the Fil-C GC instead of its own GC and to make it use a capability per JS object.
On the other hand, Chromium's JS engine (V8) does a bunch of crazy stuff with pointer encoding, so the best you could do there is probably a single arena for the whole JS heap.
Also, JavaScriptCore has a well-supported mode that involves not only zero JIT but a fully portable C++ interpreter. Not sure V8 has that.
NIST probably had this one filed and ready to announce years ago
like those news agencies have obituaries of famous old people pre-written
I know a regular old geezer who's written his own obituary. Publish this when I die.
I bet famous people have their people write one to distribute immediately.
Also, writing those for your family sucks, easier to do it when they are alive and can tell some key stories.
There's something funny about the site needing JavaScript to display anything
Why is this 8.8?
It's because User Interaction is Required. CVSS 10 would be the case where everyone can be exploited without interaction.
Interestingly the 8.8 is more alert-worthy than the 9.8 and 10 cvss, because there is a need to be alerted of the current security risk, whereas with a cvss 2 vuln, there is nothing to be done by users, only admins.
As somebody who prefers to browse with JS off whenever possible, there's something absurd about the balance everyone takes for granted between (A) your personal safety against a devastating hack by malicious code and (B) surveillance advertising.
"Sorry, but to enter this shop you need to take one of the used syringes from that pile some dude delivers every day and poke yourself with it."
This seems irrelevant as the issue talks about being exploitable with a crafted HTML page, no mention of JS. If true, you would be able to be hit without js enabled.
It mentions a type confusion in V8. Is it possible to trigger that without JS enabled?
The "all chromium versions" part of the title is also misleading, most browser CVEs do not distinguish between "untested lower bound" vs "affects all" (even though it seems like it'd be trivial to bisect).
Chromium, or just Chrome?
Only a score of 8.8?
RCE inside sandbox, so requires chaining with another 0day.
What exactly does "RCE inside sandbox" describe that goes beyond "the webpage can supply arbitrary JavaScript and the JavaScript engine executes it", but is still isolated from the system?
It means it can execute arbitrary machine code in the sandbox.
I think people would like to understand what the "sandbox" is here and what isolation does it provide, is it an unprivileged process? something chromium specific? a v8/JS thing? etc.
Seems to use OS-specific kernel syscall filtering facilities.
Windows: https://chromium.googlesource.com/chromium/src/+/HEAD/docs/d...
Linux: https://chromium.googlesource.com/chromium/src/+/0e94f26e8/d...
great link, thanks
V8 also has its own sandbox, which I believe exists in that sandbox. I assume that's the one this exploit has RCE in, but its unclear.
https://chromium.googlesource.com/v8/v8.git/+/refs/heads/mai...
I would assume in this case that there's full renderer control, not just a bypass of the in-process isolation.
Okay, and why is that more of a security risk than executing arbitrary JavaScript in the sandbox?
because with proper code exec you can trigger other bugs to escalate beyond the sandbox, whereas with JS you'd have to find a bug to escape from JS to native
can't get a proper ios/Android RCE with just JS code exec
It can do some things that JS can’t do, such as invalid pointer writes. But you are correct that this doesn’t automatically imply system access.
Because Javascript theoretically can't just access files on disk. Control over the render would let you do that, if not for the process level sandbox, which constraints things like file access, system, calls, etc.
But the process is still more capable than the VM. The process can talk to other processes via IPC, for example.
That's why you don't go from "javascript -> computer is taken over", instead you go from "javascript -> renderer control -> computer is taken over".
Among other things, JavaScript in the browser has no way to even express "kill PID 1234 on the user's machine" or "list the contents of `C:\Users\Documents` and upload all of the files" or "spawn cmd.exe on the user's machine". How would you even do these things if you could run any JavaScript in the browser? You can't.
However, chrome.exe itself does because it's a native application, as is the sandboxed JavaScript interpreter inside of chrome.exe.
(This is a very oversimplified explanation but I think this is the disconnect people are having)
> JavaScript in the browser has no way to even express ... "list the contents of `C:\Users\Documents` and upload all of the files"
this is besides the point, but javascript has the file system api.
anyways to your broad point, i dont think this is convincing. What's the difference between not having an api vs having an api that is disabled (e.g. the syscall exists but is filtered). Either way you are not taking the action. RCE in the sandbox is an important step in the bigger exploit chain, but not because you can express things in the traditional syscalls inside the sandbox.
> It means it can execute arbitrary machine code in the sandbox.
Well which is precisely why we have sandboxes.
To me "executing arbitrary code in the sandbox" is similar to "I don't give a flying fuck for it's what a sandbox is for".
More information is needed. As someone commented: this has to be paired with at least another exploit to make anything remotely useful.
A sandbox is a sandbox. We want to understand how "code running in a sandbox" is "actively exploited".
Memory isolation having one tab or account open on your bank and another on this page does not mean it could leak across the sandbox and steal bank account details but anything inside of your general page content can be lost
It means it can execute native code inside the sandbox, as opposed to Javascript. While still sandboxed, this lets it access some parts of the attack surface that JS would not have been able to, some of which may have other exploits that allow escaping the rest of the way.
Chrome runs webpages in individual sandbox processes with very low privileges, as a defense-in-depth strategy. It generally requires at least two exploits to actually affect a user--first, get RCE in a sandboxed process, then find a separate vulnerability that lets you escape the sandbox process entirely. For this bug to have actually been used in the wild, there was almost certainly a second bug as well.
what is online ad networks for $100, alex
I don't know why this is being downvoted. This is called malvertising and its one of the most significant vectors for exploiting a vulnerability like this. Its happened multiple times over the last two decades.
My read of Google's disclosure is that there is likely no known escape from the sandbox. I don't agree this would be reported this way just because "user action" like "using web browser" is required. Even if this individual CVE is correctly an 8.8 there would be a critical assessment of a known chain. The only reason there wouldn't be, would be if the other vulnerability is known to Google but has no patch yet.
This doesn't affect the score though, the reason there's 1.2 points less than the max is because there is a Required User Interaction. The user needs to visit a specific html page.
Even with the sandbox protection layer, the rest of the parameters are maxed out.
Doesn't everyone else immediately update everything on their computer before they start doing anything?
what planet are you living on
$1k for this vuln is laughable. If the researcher wrote an exploit as the nday exploit devs did and sold it in the gray market they would of got significantly more.
Anyone who sells such an exploit should go to prison.
Agreed--if you can catch them of course.
Just one more reason to never use Chrome. Their removal of MV2 to prevent UBlock Origin from working is another.
Which browser has a better security track record?
Vanadium makes improvements on Chromium. https://grapheneos.org/features#vanadium
Right, but it's value-add on a derivative, not its own standalone engine.
Most of those are just changing flags, not really unique development. Like "disable JIT" is a Chromium flag. "Zero-init everything" is a Clang flag.
Firefox with uBlock Origin. It’s astonishing how many exploits uBO stops before they ever reach your browser engine. It’s the antivirus of the 2020s.
I suggest Zen browser (fork of FF), it feels closer to chrome.
In a good way?
I hear about Zen. Random q:
It can’t trick Canva into letting you use the color picker, or otherwise enable it, can it - if someone happens to know?
(What a dumb feature to be locked to the Googlesphere.)
What does it mean "closer to chrome"?
Brave would be a much better option if you want security and good adblocking.
Firefox absolutely does not have a better security track record than Chromium browsers and on top of it you’re recommending an extension as a security measure oh my god man this comment needs to be flagged dead
edit: links
https://www.reddit.com/r/GrapheneOS/comments/1unhtxu/initial...
https://grapheneos.org/usage#web-browsing
I'm willing to believe that stock chrome has a better record than stock Firefox, but
> and on top of it you’re recommending an extension as a security measure
... Yes? Why can a browser extension not be a security measure/improvement?
The idea here is that uBlock filters the domains that may serve the malware in the first place. It basically works the same as a DNS filter.
Which you can also easily do with uBlock Origin Lite in Chrome/Chromium.
Despite what people are saying here, chrome has a really excellent track record. Nobody is perfect. Switching just because chrome got exploited one time will likely result in you switching to something worse.
If you're paranoid, disable JIT.
Or disable JS altogether, and enjoy many sites working much quicker. Many others fail & need to be selectively allowed, but it's been worth it.
If we needed any more.
Chrome product management is horrible. Chrome software engineering is some of the best ever done.
(And no, I don't use it except for testing).
I don’t disagree, two or more things can be true at once.
That said I still use Firefox for other reasons.
I simply don’t trust google, I don’t trust Mozilla either but I do trust them more than Google and you do kinda have to have a browser to function in the modern world.
Oh, right, because other browsers never have bugs.
Of all the reasons to use non-Chromium browsers whenever possible(!), this isn’t really on the list.
chrome has more bugs, not necessarily because it's less secure, but its popularity makes it a bigger target, so more bugs are found
This is like saying never use seatbelts because people still die in car accidents.
Chromium is still far superior on the security front than any other browser.