Live data from Hacker News

Actively exploited sandbox RCE in all Chromium versions

nvd.nist.gov

381–390 of 527 posts

Re: Actively exploited sandbox RCE in all Chromium versions

#381

Earlier quoted context omitted.

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.

Enterprise Software

Re: Actively exploited sandbox RCE in all Chromium versions

#382
post #282

Earlier quoted context omitted.

Not always. Consider an SPA that connects via WebSockets and streams in data, adding points to a chart. The JS-less alternative would be refreshing an SVG or even the whole page once a second. The SPA is clearly more efficient here (unless someone screws it up badly).

I wouldn't consider that an SPA at all, it's just a page with an interactive element. An SPA is something that renders everything client-side and uses a generic client API to talk to the backend. A telltale sign of an SPA is that the first thing you see when you open it is some sort of loading indicator instead of the actual page you're visiting.

No, the telltale sign of a SPA is that it’s an app that’s a single fucking page, lol

Please stop changing the definitions of explicit words and phrases - to anyone reading this!

Re: Actively exploited sandbox RCE in all Chromium versions

#383
post #92

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…

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…

Isn’t the implication that the vulnerability had already been found and exploited instead of reported to Google, because its value to Google was so low? Whoever found it originally had more incentive to sell it on the grey/black market. Or is the incentive structure truly different for vulnerabilities discovered to be already in the wild?

Re: Actively exploited sandbox RCE in all Chromium versions

#384

Earlier quoted context omitted.

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

Telling someone the steps to rob a bank world probably catch you some charges, I'm assuming.

Are true crime authors going to jail? Or even authors of heist fiction?

Re: Actively exploited sandbox RCE in all Chromium versions

#385
post #295

Earlier quoted context omitted.

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)

You should add a disclaimer that you are the CEO of Fil-C. /s In the context of this vulnerability, I doubt memory safety would have made much of a difference. This is a great reminder though, currently doing a full userspace replacement on my 3D printer and Fil-C might be just what I need for the irreplaceable C parts.

How would memory safety have not made a difference?

Re: Actively exploited sandbox RCE in all Chromium versions

#386

Earlier quoted context omitted.

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

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

> easy to be safer

It took over two years and help from contributors to get to the point where WebKit could be made fully memory safe.

Re: Actively exploited sandbox RCE in all Chromium versions

#387

Earlier quoted context omitted.

CVE severity is a terrible way to do this. If you follow the cybersecurity space you should know why.

It's a simple multiplier number and you can set a cap on it (and payout amounts). Where's the fire?

CVEs are handed out like candy for non issues, the severity rating system isn’t a serious evaluation of the actual severity (eg a vulnerable function may not even be compiled in), the scoring is inconsistent and subjective and frequently inflated to make the severity seem worse, and with the AI flood they have a massive backlog of handing out CVEs.

Like look at CVEs curl dealt with at one point that were just completely bogus and given huge severity ratings to start with.

But honestly if you’re the one proposing a “simple solution” maybe do some research yourself.

Re: Actively exploited sandbox RCE in all Chromium versions

#388
post #350
post #31

Earlier quoted context omitted.

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.

uBlock Origin won't help with this kind of targeted exploit, and Firefox has a much worse security track record.

It absolutely does help, because it blocks hundreds of thousands of shady origins.

Re: Actively exploited sandbox RCE in all Chromium versions

#389
post #31

Earlier quoted context omitted.

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.

uBO stops exploits? Source?

It blocks many shady domains, which stops many exploits before they ever reach your browser.

Re: Actively exploited sandbox RCE in all Chromium versions

#390
post #343

Earlier quoted context omitted.

Wow... I understand your point but if you feel that strong about gates using js on his personal website, it is a bit harsh isn't it? Could have multiple reasons why it is needed. Especially for someone with such a huge follower base. Lazy loading, tracking, client based adjustments, using a framework, fun [:)]... I could go on with a 100 more points why js might be needed.

HTML has lazy loading. There not a lot of reason to not have at least a fallback to serve your text-only content without JS.

That is true, but it is very basic and depending on the browser how it is implemented. On traffic heavy sites, which I assume gates blog is, js gives you full control over what get loaded when and at the same time enables tracking how far the user read the article and which parts he most likely skipped. I am not saying that this is good, however if you have these requirements js is a valid choice.
Post reply on HN