CVE-2026-85046: a Chromium sandbox escape already exploited

What we actually have

The vulnerability is tracked as CVE-2026-85046 in NIST’s NVD. It was picked up late in the evening of 4 September 2026 on Hacker News, where the thread gathered 358 points and 203 comments — a level of attention that, on that site, tends to mark the flaws practitioners consider structural.

We have to be explicit about our limits here. As we write, our only source is that NVD entry and the thread relaying it. We have not been able to corroborate the vulnerability against a second independent source. Everything that follows about the nature of the flaw is therefore reported rather than confirmed, and you should treat the NVD entry itself as the reference to check first.

A sandbox escape, and why it is a category of its own

The flaw is reported to be a sandbox escape affecting Chromium. This is the class of vulnerability browser teams fear most, and the reason is architectural.

A modern browser assumes the code it runs is hostile. Every page executes inside an isolated process with no direct access to the file system, to devices, or to other tabs. That compartment is the last line of defence. A bug in the rendering engine alone stays contained. A sandbox escape removes the wall: code from a web page reaches the operating system with the privileges of the process hosting it. These flaws are rarely useful on their own — they are chained with others, and that is exactly what makes them valuable to an attacker.

The entry is also reported to note exploitation already observed in the wild. If that holds, there is no window between disclosure and patch to plan around: it has already closed, from the wrong side.

The real scope: well beyond Chrome

Chromium is not just Chrome. It is the foundation of a large share of desktop and mobile browsers, and above all of Electron, the framework that ships a full browser inside a desktop application. Workplace chat clients, code editors, video-conferencing apps, internal tools: many of them carry their own copy of the engine.

It is that second group that creates the problem. A browser updates itself, usually within days. An Electron application moves at its vendor’s pace: the vendor has to pull in the new engine build, retest, then ship. The lag is measured in weeks, sometimes longer. Across a fleet of machines, the exposed surface outlives the browser patch by a wide margin.

What you can do right now

Restart your browsers. A downloaded update only takes effect when the browser is relaunched, and a machine left open for several days is still running the old version — this is the cheapest step available to you and the one most often skipped.

Then inventory your Electron applications. They appear in no browser update dashboard, and nothing will prompt you about them. Knowing which ones you run, and which vendors are slow to rebase, is what turns this from an abstract advisory into a list you can work through.

Finally, keep an eye on the NVD entry. It remains the source to consult as vendors publish their own fixes, and as the affected version ranges get pinned down.

We will update this article as soon as a second source lets us confirm the exact scope of affected versions. In the meantime, what is already on the table is enough to justify a restart.