Actively exploited sandbox RCE in all Chromium versions • Hacker News Board

Re: Actively exploited sandbox RCE in all Chromium versions

#371

Post by socalgal2 » Sat, Sep 05, 2026, 2:00 PM UTC

roywiggins wrote: post #253

socalgal2 wrote: post #218

Earlier quoted context omitted.

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 p…

> I chained this bug with an n-day sandbox escape and flagged the v8CTF. https://serotav.github.io/Writeups/v8/when-sorting-leads-to-...

Then what it was chained to is the real issue, not this one. The entire point of having webpages run in their own process is to prevent bugs like this one from doing worse. If you're claiming this bug is the bug that matters, you're effectively claiming they shouldn't need to run pages in their own process and just trust that there are zero bugs. No major browser does that. Not Firefox, not Safari, and not Chromium.

that's why bugs in the webpage process pay out very little. Without a worse 2nd bug, they are less serious. Bugs that let you RCE outside the webpage process pay much higher.

Re: Actively exploited sandbox RCE in all Chromium versions

#372

Post by ruuda » Sat, Sep 05, 2026, 2:01 PM UTC

internetter wrote: post #270

ruuda wrote: post #257

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

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

I think my subjective feeling is in that ballpark, yes. There are of course many sites that are more like web apps that require js, but those are relatively trusted, I added exceptions for them long ago. For sites that I visit for the first time, I think more than half still work to some extent. Maybe they are slightly broken, but at least I can read the page. I’d say around 20–30% of the web even gets _better_, because you don’t get ads or cookiewalls. But then there are also many sites that just remain a blank page, not even showing a message that js is required. (And as the sibling comment points out, recently Anubis is also becoming more common; maybe in recent months it’s closer to 40–50% unusable.) When I hit that, often I am reminded that I wasn’t that interested anyway, and I close the tab. So maybe it’s more than 30% that breaks, and a more accurate statement would be “of the sites where I ended up reading a page, I had to opt in to js about 30% of the time”.

Re: Actively exploited sandbox RCE in all Chromium versions

#373

Post by magicalist » Sat, Sep 05, 2026, 2:02 PM UTC

roywiggins wrote: post #253

socalgal2 wrote: post #218

Earlier quoted context omitted.

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 p…

> I chained this bug with an n-day sandbox escape and flagged the v8CTF. https://serotav.github.io/Writeups/v8/when-sorting-leads-to-...

I believe that means the v8 sandbox, not a renderer sandbox, based on the v8CTF reference.

Re: Actively exploited sandbox RCE in all Chromium versions

#374

Post by odyssey7 » Sat, Sep 05, 2026, 2:05 PM UTC

How many Heartbleeds[1] must software users and our national security interests endure before the industry treats memory safety as a best practice for systems with exposure to the Internet?

The V8 vulnerability being exploited today, CVE-2026-85046, is listed in NVD under CWE-843, "Access of Resource Using Incompatible Type ('Type Confusion')."[2] On this class of vulnerabilities, MITRE explains:

> When a memory buffer is accessed using the wrong type, it could read or write memory out of the bounds of the buffer

Memory safety is specifically intended to prevent errors like these from becoming arbitrary out-of-bounds memory access and native code execution. Even type safety --- from the 1970s --- can prevent type confusion.

The CISA and the NSA have called for the adoption of memory-safe languages.[3] We exercise poor engineering judgment and poor ethics, as an industry, when we continue to expose users to classes of wholly avoidable security weaknesses in Internet-facing software.

[1] https://en.wikipedia.org/wiki/Heartbleed

[2] https://cwe.mitre.org/data/definitions/843.html

[3] https://www.nsa.gov/Press-Room/Press-Releases-Statements/Pre...

Re: Actively exploited sandbox RCE in all Chromium versions

#375

Post by kccqzy » Sat, Sep 05, 2026, 2:05 PM UTC

noduerme wrote: post #240

david_shaw wrote: post #20

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

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 effec…

That’s exactly right, and applies to more than Google. I can’t think of a single browser vendor that would think a single vulnerability materially causes reputational damage.

Re: Actively exploited sandbox RCE in all Chromium versions

#376

Post by parineum » Sat, Sep 05, 2026, 2:18 PM UTC

socalgal2 wrote: post #371

roywiggins wrote: post #253

Earlier quoted context omitted.

> I chained this bug with an n-day sandbox escape and flagged the v8CTF. https://serotav.github.io/Writeups/v8/when-sorting-leads-to-...

Then what it was chained to is the real issue, not this one. The entire point of having webpages run in their own process is to prevent bugs like this one from doing worse. If you're claiming this bug is the bug that matters, you're effectively claiming they shouldn't need to run pages in their own process and just trust that there are zero bugs. No major browser does that. Not Firefox, not Safari, and not Chromium.…

Then just call them both one exploit that allows arbitrary sandbox escape.

Re: Actively exploited sandbox RCE in all Chromium versions

#377

Post by fguerraz » Sat, Sep 05, 2026, 2:25 PM UTC

kllrnohj wrote: post #359

Gabrys1 wrote: post #276

Earlier quoted context omitted.

Knowing the vulnerability, creating an exploit might be relatively easy now that we have AI to figure the boring stuff out.

This "only" escapes the JavaScript sandbox. You still need to chain it with an escape for the process sandbox. So it's not just the boring stuff of turning a predictable crash into arbitrary execution, but also finding a second RCE vulnerability to chain this with

If it’s being exploited “in the wild”, it means someone has already found how to chain it, otherwise what would be the point?

Re: Actively exploited sandbox RCE in all Chromium versions

#378

Post by marcosdumay » Sat, Sep 05, 2026, 2:27 PM UTC

grishka wrote: post #256

timr wrote: post #228

Earlier quoted context omitted.

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 stu…

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

> Why the fuck would anyone ever want that? What's so hard about simply changing the innerText or inserting elements or whatever?

It's so that you have the page reflecting your data at all times.

The browsers should have been written this way, instead of having byzantine update functions with all forms and a pair of *Text to rule them all. But creating it in Javascript is a really bad idea.

Re: Actively exploited sandbox RCE in all Chromium versions

#379

Post by no-name-here » Sat, Sep 05, 2026, 2:28 PM UTC

odyssey7 wrote: post #374

How many Heartbleeds[1] must software users and our national security interests endure before the industry treats memory safety as a best practice for systems with exposure to the Internet? The V8 vulnerability being exploited today, CVE-2026-85046, is listed in NVD under CWE-843, "Access of Resource Using Incompatible Type ('Type Confusion')."[2] On this class of vulnerabilities, MITRE explains: > When a memory buff…

[dead]

Re: Actively exploited sandbox RCE in all Chromium versions

#380

Post by muvlon » Sat, Sep 05, 2026, 2:32 PM UTC

eru wrote: post #61

publlus_enigma wrote: post #55

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.

What would that even look like? What is "benign"? The browser environment already has pretty strict rules for what the JS can do. It's not allowed to read your files, see your webcam without permission, know about other tabs or windows etc.

The problem here is that the browser failed to correctly implement those rules. If the chromium team cannot do that, what makes you think they can implement any other kind of "benign code" verification with zero bugs?