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.
Actively exploited sandbox RCE in all Chromium versions
381–390 of 527 posts
Re: Actively exploited sandbox RCE in all Chromium versions
#382Earlier 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.
Please stop changing the definitions of explicit words and phrases - to anyone reading this!
Re: Actively exploited sandbox RCE in all Chromium versions
#383Let'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…
Re: Actively exploited sandbox RCE in all Chromium versions
#384Earlier 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.
Re: Actively exploited sandbox RCE in all Chromium versions
#385Earlier 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.
Re: Actively exploited sandbox RCE in all Chromium versions
#386Earlier 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.
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
#387Earlier 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?
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
#388Earlier 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.
Re: Actively exploited sandbox RCE in all Chromium versions
#389Earlier 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?
Re: Actively exploited sandbox RCE in all Chromium versions
#390Earlier 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.