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.

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.

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?

The potential damage is all to users bound by terms and conditions, who are unlikely to collect damages successfully from a vendor. Structurally, vendors don’t have to care. Therefore, vulnerabilities have little direct financial value to a vendor.

It’s natural to feel cognitive dissonance because the value to the vendor is so disproportionate to the potential harm to users, but the incentive structure is what it is.

A vulnerability which lets an attacker harm the vendor has much higher direct financial value.

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

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

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.

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.

> 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

With such low payment, it makes one wonder how many exploits exist which were sold to 3rd parties and are currently used in the wild without Google even knowing about it.

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

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.

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.

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.

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

What? That's not how you calculate the value of something at all.

The value is not based on the prevention, it's the cost of the cure.

"because researchers shouldn't hold bugs for ransom or demand high payment" Maybe they should now, not like anyone else cares about ethics anyway.

People are free to pool their money and offer higher bounties.

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.

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

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.

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

Seems like it was worth $1000 to the researcher in question.

> Ethical disclosure is a complicated topic, because researchers shouldn't hold bugs for ransom or demand high payment.

I mean, why not?

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.

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

My thought exactly.

Which is why I have NoScript in my Firefox and have gotten used to manually enabling javascript for select pages. Small price to pay.

Unfortunately the web is full of trivial websites that have no business running javascript. Recently wanted to read the famed post on Gates Notes. But for some reason Bill requires javascript to render text and images. Which reminded me Bill is not a person with good judgement on matters of IT and policy. Time saved.

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

That's basically the comment I was just going to write but you made me not need to.

We need simpler protocols and formats, especially those that are used over the internet. I want everyone to really start fighting for this.

I always use a browser that doesn't run any scripts (w3m) for both this reason and others. It hurts when I see websites that don't work without js. A bit funny though that this page is one of them so I was not able to read it.

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.

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

In the future we can ask that your JaveScript and Wasm comes with a proof of being benign.

V8 as a runtime goes far deeper than just webpages.

> Unfortunately, it breaks about 30% of the web.

More like 99%

I use Firefox with Noscript and I'm _totally aware_ that almost no website works without allowing it JS.

Even using Noscript it's becoming more and more exhausting every year, it's plain impossible to browse the internet without JS at all.

> Unfortunately, it breaks about 30% of the web.

Only 30?

> Unfortunately, it breaks about 30% of the web

Only 30%? In 2026? With CloudFlare and Anubis et al absolutely everywhere? Not to mention SPAs

Don't. Garbage Collector hurts your memory

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.

Just in time.

There's been a Chrome CVE like every week ever since it came out.

Is graphene even affected? JIT is disabled in default configurations.

This issue is already fixed in Google Chrome (152.0.7977.83)

The release version just now updated to 152.0.7977.83 which has the fix.

I think it's the first one where the Chrome version fixing it has no Manifest V2 support at all.

Monocultures are great!

Yes, it says right in the CVE

> allowed a remote attacker to execute arbitrary code *inside the sandbox*

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

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

The title is bad, it is not sandbox escape, it is "RCE inside the sandbox", so only RCE when sandbox is disabled.

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)

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.

The Chromium issue is not public yet, so let's go with a very simple example.

Let's say that you have a type confusion bug that (in terms of the interpreted language) allows you to use an Integer variable as an Array.

That sounds nonsensical when just considering the high-level language, but your computer is going to need something to work with when running a script. For an Integer variable it will for example store the value, and for an Array it would store a pointer to a data area (and that area then contains values).

Now, if the interpreter loses track of which type a certain variable is, then it will also not know whether to interpret the internal data as a plain value (arbitrarily chosen by the script/attacker) or a pointer to well-formed data (carefully chosen by the runtime).

As an immediate step, letting the attacker use an address of their choosing for array operations would allow them to read and write arbitrary memory that is reachable with this form of addressing.

I'm putting specific emphasis on "form of addressing" here, because the v8 authors have considered this possibility and put additional protections in place. Within the sandbox, "addresses" are limited to a size of 32 bits, and address within a dedicated 4 Gigabyte area that is specifically for interpreter data. Within that area you are not going to find a lot of critical data to affect outside operations, you'd have to find a way to escape that memory area first.

The next part is going to be a bit hazy because it's been some time since I did Chromium exploitation, and getting code execution within the sandbox from data writes is itself not an easy task.

Now, we have established that there is not a lot of terribly important data within the 4 GB area. The data managing the interpreter lives outside, and any JITed code will also live outside because it needs different access permissions. We only really get to play with Objects and their data.

Objects handling executable code are rare, but there are a few that are at least adjacent. Last time I checked, WASM was one feasible choice where you get reasonably predictable results with custom data, as it included a pointer to actual executable code that represents the WASM program.

Under the assumption that the WASM interpreter/compiler does its job correctly the full block of executable code will not be very interesting. However, any integer constant in the program will end up somewhere within the executable code, and that would give you enough controllable data to encode one or two arbitrary instructions and a relative jump to the next integer constant. To start execution at the first integer constant, we'd then just modify the Object data of the WASM program to slightly offset the entrypoint.

And that's the short form of a possible (and likely outdated) way of getting semi-arbitrary code execution within the sandbox (as we are running as a WASM program, and therefore have all the usual syscall restrictions and other security features engaged).

Wait, you have that working? What's the lowest friction to run it? Like, VM or docker container or...

For it to be memory safe, do you have to disable the JIT?

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

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.

RCE inside sandbox, so requires chaining with another 0day.

Is that frequent enough? I mean an update might be issued after you start doing something.

what planet are you living on

Anyone who sells such an exploit should go to prison.

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

Which browser has a better security track record?

Of all the reasons to use non-Chromium browsers whenever possible(!), this isn’t really on the list.

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.

Oh, right, because other browsers never have bugs.

If we needed any more.

chrome has more bugs, not necessarily because it's less secure, but its popularity makes it a bigger target, so more bugs are found