Chromium sandbox RCE is being exploited in the wild — patch today

What happened

NIST published CVE-2026-85046 as an actively exploited sandbox escape affecting all current Chromium versions. The advisory lands with the highest urgency label the NVD uses: exploitation observed in the wild, no mitigation short of patching, and a CVSS in the range where security teams stop asking questions and start pushing hotfixes.

The bug is a sandbox break, not a renderer crash — meaning a compromised tab can execute code on the host operating system, not just inside its own process. That is the class of vulnerability every browser-security model is designed to prevent, and it's the reason "just visit a page" is enough to own a machine. Google's own severity taxonomy reserves "Critical" almost exclusively for this class, and the CVE metadata suggests the exploit chain requires no user interaction beyond page load.

Google has begun rolling out a patched Chrome build on the stable channel, and Microsoft is expected to follow within 24-48 hours for Edge. But Chromium is not just Chrome. The same code powers Edge, Brave, Opera, Arc, Vivaldi, Samsung Internet, and — critically for developers — every Electron and CEF-based desktop app in production. Slack, VS Code, Discord, 1Password, Figma desktop, Notion, Postman, Signal desktop, and thousands of internal tools all bundle their own Chromium fork. Each one needs its own release cut against a patched base.

Why it matters

The interesting question isn't whether Chrome will patch — it will, quickly, and Chrome's auto-update is the fastest patch delivery mechanism in the industry. The interesting question is how long the long tail takes.

Electron's median lag between an upstream Chromium security release and a patched Electron release has historically been 7-14 days, and the median lag between a patched Electron and a patched downstream app is another 2-4 weeks. That's the window attackers care about. A drive-by exploit against Chrome desktop closes within hours. The same exploit against your Slack client stays open for a month.

This matters more in 2026 than it did in 2020 because the surface area has exploded. The average developer laptop now runs somewhere between 6 and 15 Electron apps simultaneously, each one a full Chromium instance with its own release cycle, its own security posture, and its own "we'll ship the update next sprint" backlog. Enterprise fleets are worse — internal Electron tools built on ancient Chromium versions are the norm, not the exception. A Duo Security survey from earlier this year found that 41% of enterprise-deployed Electron apps were running Chromium builds more than 90 days behind stable.

The community reaction on HN reflects the frustration. The top comment on the thread points out that Chromium's sandbox has now been the sole meaningful barrier between the web and the OS for over a decade, and every few years a break like this reminds us how much load that one layer is carrying. Others noted the irony that the same week security researchers were debating whether to move away from the Chromium monoculture, the monoculture handed everyone the same critical bug at the same time.

There is no known mitigation short of patching — no config flag, no extension, no "disable JavaScript on untrusted sites" workaround that fully closes the hole. The exploit path runs through the renderer sandbox itself, which is where JavaScript executes even when JIT is disabled. Site isolation helps limit blast radius per-origin, but it does not prevent the escape.

What this means for your stack

If you ship an Electron app, an CEF embed, or anything else that bundles Chromium, you have work to do this week. The playbook:

1. Check your Chromium version now. In Electron, `process.versions.chrome` at runtime, or check the Electron release notes for the version you ship. In CEF, check the branch number. If you're on anything older than the version Google shipped this week, you're vulnerable.

2. Cut a release, even if you weren't planning to. The gap between "patched Electron available" and "patched app in users' hands" is where the exploitation window lives — closing it is your job, not Electron's. Auto-update matters here. Apps with Squirrel/electron-updater configured can push a fix in hours. Apps that rely on users downloading a new installer from a website will be exposed for weeks.

3. Audit your bundled Chromium exposure across the org. Internal tools count. That Grafana kiosk running on a display. The Electron wrapper someone built around your admin panel. The old version of Postman on the QA team's machines. If it renders HTML from anywhere but a known-good source, it's in scope.

4. For web apps, tighten CSP and reduce third-party script exposure. You can't patch the browser your users run, but you can reduce the attack surface. A drive-by exploit needs a page to land on. Fewer ad networks, fewer third-party scripts, stricter CSP — none of these stop the CVE, but they reduce the probability that the exploit reaches your users through your surface.

For pure web-app developers with no desktop footprint, the immediate action is smaller but not zero: force a Chrome update prompt for admin users, and treat any session originating from a stale Chrome build as suspect for the next few days.

Looking ahead

The Chromium monoculture is a feature and a bug. It gives us one browser engine to test against, one rendering model to target, one JavaScript engine to optimize for. It also means one bug lands on ~90% of the world's browsers simultaneously and creates a coordination problem the entire desktop-app ecosystem has to solve at once. Expect a rough week for Electron maintainers, a rough month for downstream apps, and a slow trickle of "we finally updated" release notes stretching into Q1. If you ship desktop software, this is the moment to ask whether your update cadence can actually meet a same-week SLA — because next time, and there will be a next time, it might not be a sandbox escape. It might be worse.