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.
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.
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 absolutely should. One of the points of bug bounties is to discourage people from selling to the black market.
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".
AP recommends spaces around them, whereas Chicago doesn’t
besides if we’re critiquing incorrect following of English orthography
—Sentences should be capitalized
—The word “don’t” requires an apostrophe
—End sentences with a period
—That’s incorrect usage of an em-dash at the end there — but what does it matter anyways ;)
And yes you cannot care about grammar that is fine but calling someone a personal insult because they pointed out something impersonal in your comment is not ideal also and is unusually catty.
I hate that it's basically become the little hitler moustache of punctuation. There was at least one guy who was really enjoying his tiny little moustache until he couldn't anymore. That is the emdash for me.
Legendary.
Miss that shit too.
Ez way to shit on Windows users who had to double up endashes like they were impoverished.
I guess in your analogy the double endash is Stalin’s mustache and the Soviet Union in general - Gaudy, excessive, starving for more
# 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
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!
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).
* 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.
Sound very interesting!
There's no way money is the motivator.
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.
"Safety" is also a relative thing, when the world is safer for one party, it is usually worse for another.
"Making money from bugs" is not solely a black-market activity. There are plenty of grey and even white hat activities in this market.
Yeah let's see how this plays out, paying people less than their time is worth for RCEs.
Now exploiting them? Yes that's a crime.
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.
No it’s not lol
... 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.
It just isn’t what free speech is.
It’s a separate thing.
Speaking more generally, don't let your ideals bias your judgment. Just because you support policy X and also view ideal Y as good that doesn't mean that X isn't detrimental to Y. It's important to be objective about these things.
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.
Even a resume item.
Remember that you can sell the same vulnerability to multiple people: it's software you can copy.
$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.
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).
> 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
How many PMs are making more than bug bounties to fetch coffee and bagels?
Their priorities are all out of order.
Having just a Sandbox RCE is neat, I've got some on my laptop currently, but it's just a piece of the puzzle.
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.
On average, probably not that much. What's the amortized cost of all testing, static analysis, and audit / code review, per "prevented potential bug"?
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.
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
nothing will change until big tech can no longer rip off security researchers
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.
> 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.
I mean, why not?
in the darkweb, due to crypto, a lot. there is where the $ is, whether it's stealing crypto directly or phishing developers.
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.
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.)
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.
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.
Uh…no?
You’re presumably talking about specific terrible prebuilt frameworks - not someone building a nice vanilla SPA.
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.
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.
Like cellphones, javascript became necessary if you want to use webmail, access your bank's website, or whatever.
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".
It's not the Bonzi-buddy and driveby-installed IE toolbars wild west of the early 00s.
https://github.com/GrapheneOS/Vanadium/releases
https://github.com/brave/brave-browser/releases
Only if you use Nightly wait maybe not.
> 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.
> allowed a remote attacker to execute arbitrary code *inside the sandbox*
(Posted from memory safe WebKit; i.e. WebKit compiled with filcc and all of WebKit's dependencies compiled with filcc.)
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
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
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 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.)
I have a new tech called SaRCAsm, which is a memory-safe assembler. So the next step is a "Sarcastic JIT" :-)
"CISA maintains the authoritative source of vulnerabilities that have been exploited in the wild."
I have a feeling someone’s going to make an open source browser using Ladybird’s engine before Ladybird has official binaries.
{
int msgType;
union {
char *name;
int nameID;
};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...
Is this chained with n-days?
Those folks would not be disclosing their sandbox escape unless they were good guys.
(Posted with a memory safe WebKit, Fil-C FTW)
posted from my outdated chrome android which crashes when i open substack
So maybe we're going to see another CVE for the sandbox escape soon?
like those news agencies have obituaries of famous old people pre-written
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.
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.
"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."
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).
Windows: https://chromium.googlesource.com/chromium/src/+/HEAD/docs/d...
Linux: https://chromium.googlesource.com/chromium/src/+/0e94f26e8/d...
https://chromium.googlesource.com/v8/v8.git/+/refs/heads/mai...
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)
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.
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".
can't get a proper ios/Android RCE with just JS code exec
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".
Even with the sandbox protection layer, the rest of the parameters are maxed out.
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.
(And no, I don't use it except for testing).
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.
If you're paranoid, disable JIT.
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.)
edit: links
https://www.reddit.com/r/GrapheneOS/comments/1unhtxu/initial...
> 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?
Chromium is still far superior on the security front than any other browser.