Short version: yes. Long version, because you’re going to have to justify the maintenance window to someone who thinks “sandboxed” means “harmless” — read on.
On September 4, 2026, Google pushed an out-of-band Stable channel update for Chrome and did the thing they only do when it’s serious: confirmed that CVE-2026-85046 is being exploited in the wild. Remote code execution inside the renderer process. Windows, macOS, Linux — the desktop trio, all of it. This isn’t a theoretical CVSS-inflated advisory that sits in your backlog until next patch Tuesday. Somebody already has a working exploit and is using it on somebody.
Let me hand the microphone to the voice in every ops channel, because he’s already typing.
“It’s contained by the sandbox. The renderer can’t touch the OS. Why am I dragging everyone through a forced restart for a bug that can’t escape the tab?”
Because “can’t escape the tab” and “can’t hurt you” are two different claims, and Google only made the first one.
Here’s what the sandbox actually buys you. Chrome runs the risky work — parsing hostile HTML, JavaScript, images, all the untrusted garbage the web throws at a page — inside a low-privilege renderer process. That process is deliberately caged: restricted token on Windows, seccomp-bpf on Linux, the Seatbelt profile on macOS. So when an attacker lands code execution in the renderer, they’ve got a shell inside a box with the doors welded shut. They can’t write to your filesystem, can’t spawn processes, can’t read the other tabs’ cookies directly. That’s real. The sandbox is one of the genuinely good pieces of engineering in modern computing, and it’s doing its job here.
But a renderer RCE is not the payload. It’s the front door.
“A front door to what, exactly? You’re hand-waving.”
Fair. Concretely: once you’ve got arbitrary code running in the renderer, you’re now sitting inside the process that talks to the browser process across the IPC boundary. That’s where the second-stage bug goes — a sandbox-escape vulnerability that, on its own, is unreachable because you can’t feed it input from a web page. Renderer RCE gives the attacker the position to feed it. Every serious in-the-wild Chrome chain of the last several years has looked like this: one bug to own the renderer, a second to break out to the browser process or the kernel. The renderer exploit is link one. You don’t get to shrug at link one because links two and three haven’t been chained in yet — the whole point of a zero-day being exploited is that someone thinks the chain is worth building.
And even with a perfectly intact sandbox, a renderer you control is not nothing. It can read and exfiltrate everything rendered in that site’s context, drive same-origin requests, and phish credentials with a convincing overlay. “Merely” owning the renderer is still owning the session.
“Fine. What’s the actual bug — use-after-free, type confusion, what?”
Google hasn’t said, and I’m not going to guess for you. That’s standard practice during active exploitation: they restrict bug details and even bug-tracker access until the majority of the fleet is patched, so they’re not writing the exploit dev’s changelog for them. So if you see a blog confidently naming the vulnerability class today, ask where they got it. What Google has confirmed is the part that matters operationally — renderer RCE, in the wild, patched now. The bug class is trivia; the version number on your endpoints is the thing.
“So which version am I checking against?”
Here’s the honest state of it as I write this: the advisory confirms an out-of-band Stable update on September 4 and confirms active exploitation, but the sources don’t publish a clean per-platform build number. So I’m not going to print one — not as an editorial flourish, but because I won’t put a build number in front of you that I can’t verify. A wrong “fixed” version is worse than none; it tells you machines are safe when they aren’t.
So do it the reliable way. Open chrome://settings/help on a test box, let it pull the update, and note the exact Stable build it lands on for that platform — Windows/macOS share a build train, Linux ships its own. That number, straight from your own patched endpoint, becomes your fleet baseline. The rule doesn’t depend on my memory: anything below the build your test box just installed is vulnerable. Confirm it against Google’s September 4 Stable release note before you commit it to a detection rule, then go find the stragglers.
The 2 a.m. reality is that Chrome’s built-in updater is quietly reliable right up until it isn’t — the machine that’s been on for 40 days and never fully relaunched, the kiosk that runs Chrome pinned by policy, the locked-down VDI image where GoogleUpdate got “hardened” into oblivion by someone two admins ago. Those are the ones the update won’t reach on its own. The update only takes effect after a full browser restart, and users do not restart their browser. Ever. That tab from March is load-bearing.
Check Windows endpoints locally by reading the binary’s version off disk — this is report-only:
For anything bigger than a handful of machines, don’t SSH around by hand — ask Defender, which already inventories installed software. Advanced Hunting, so you get the whole fleet in one query:
macOS and Linux, one line each — again, just reporting:
One catch worth its own sentence: --version reports the installed build, not the running one. A box can show the patched number and still be executing the old code because nobody relaunched. If you want certainty, force the restart — don’t trust that the updater and the user cooperated.
“Alright. Immediate, or can it wait for the weekly ring rollout?”
Immediate. Not because I’m caffeinated and dramatic — because “exploited in the wild” plus “high-severity renderer RCE” plus “the fix is already published” removes every excuse a change board can throw at you. The exploit exists, the patch exists, and the only variable left is how long your users keep running the vulnerable build. Ship the update to your fastest ring tonight, force-relaunch where policy lets you, and use the Defender query to name-and-shame the machines still sitting below the fixed version tomorrow morning.
Compensating controls if you genuinely can’t patch a given host this cycle: push RelaunchNotificationPeriod via policy to nag users into the restart that actually applies the fix, and keep the machine off untrusted browsing until it’s current. That’s a stopgap, not a strategy.
The sandbox held this round. Treat that as the reason you got a warning instead of an incident — not the reason to ignore it.
