What Is a Sandbox Escape?

A headline says an attacker can run code in your browser. Another says a sandbox escape. They sound like the same news. They are not, and the gap between them is roughly the gap between someone in your porch and someone in your house.

This one is worth understanding properly because it decides whether a bug is an emergency.

What a sandbox is

A sandbox is a box you put code in when you have to run it but do not trust it.

The browser is the clearest example, because it has the hardest version of the problem. Every page you open runs code written by a stranger. There is no way to check it first. So the browser runs it somewhere deliberately crippled.

Modern browsers split into at least two kinds of process:

The renderer process does the dangerous work: parsing HTML, running JavaScript, decoding images and fonts. It is the part that touches attacker-controlled input, and it is stripped of privileges. It cannot open arbitrary files. It cannot make arbitrary network connections. On a good day it cannot even ask the operating system for much, because the set of system calls it is allowed to make has been cut down to a short list.

The broker process, usually the browser process, holds the real privileges. It has your files, your cookies, your saved passwords.

The renderer cannot do anything interesting by itself. It has to ask the broker, and the broker checks. The sandbox is that arrangement: the dangerous work happens in the powerless process, and every powerful action goes through a checkpoint.

The design assumes the renderer will eventually be compromised. It is parsing hostile input all day; assuming otherwise would be silly. So the question is never whether an attacker gets into the renderer. It is what they can do once they are there.

So what is code execution inside the sandbox

This is the first of the two headlines, and it is the more common one.

An attacker finds a memory-safety bug in the renderer. A type confusion, a use-after-free, an out-of-bounds write. They build a page that triggers it, and they gain the ability to run instructions of their choosing inside the renderer process.

That sounds like the end. It is not, because of where they are standing. They are inside the box with no privileges. They have full control of a process that was deliberately built to be worth very little.

They can read what that tab is handling. They can attack the broker from a better position. But they cannot read your documents, install anything, or persist across a restart, because the renderer was never able to do those things and compromising it does not grant abilities it did not have.

This is stage one. It is serious and it is not game over.

And a sandbox escape

The second bug is the escape.

Now the attacker, running inside the renderer, attacks the boundary itself. Usually that means the interface between renderer and broker: the messages the renderer is allowed to send. If the broker mishandles a malformed message from a process it already assumes is hostile, the attacker crosses over and inherits the broker's privileges.

Other paths exist. A kernel bug reachable through one of the few system calls the sandbox still allows is a classic, because then you do not land in the broker, you land in the kernel.

That crossing is the sandbox escape, and now it is your machine.

Why exploits come in pairs

This is why you see chains. Real browser attacks are typically two bugs: one to get into the renderer, one to get out.

It is also why the economics look the way they do. A renderer bug alone is worth something. An escape alone is worth something, but it is useless without a way to reach it. The pair is worth far more than the sum, which is why exploit brokers price full chains separately and why a single renderer bug being patched is routine news rather than a crisis.

It is genuinely good engineering. Requiring two independent flaws multiplies the cost of an attack rather than adding to it.

How to check a claim yourself

Here is the part that makes you independent of headlines. Take the actively exploited Chromium bug in the news right now, CVE-2026-85046, and read the record.

The CVSS vector. This is the fast answer. The vector for this bug is AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H.

Find S. It is the scope field, and it exists specifically to answer this question. S:U means scope unchanged, the impact stays within the security boundary the vulnerable component sits in. S:C means scope changed, the bug affects things beyond it.

S:U on a browser renderer bug means no escape. The rest of that vector is useful too: UI:R means user interaction required, so someone has to visit a page, and PR:N means no privileges needed.

The description. Both NVD and CISA say this one allows an attacker to execute arbitrary code inside the sandbox. When the words inside the sandbox appear, that is stage one, stated explicitly.

The CWE. Here it is CWE-843, type confusion: the program treats a chunk of memory as one type when it is actually another. A classic renderer-compromise primitive.

The affected versions. The record bounds it at before 152.0.7977.82, which is also how you know that any claim about "all versions" is wrong.

The headline for this bug read actively exploited sandbox RCE in all Chromium versions. The record says: code execution inside the sandbox, scope unchanged, fixed in a specific build. Two errors, both checkable in about a minute.

The same idea outside the browser

The pattern generalises, and the vocabulary carries over.

Containers. A container is a sandbox built from kernel features: namespaces, cgroups, seccomp filters. Code execution in a container is stage one. Container escape is the equivalent of the browser escape, and because containers share one kernel, the escape usually means a kernel bug. This is the reason people reach for a VM when the workload is genuinely untrusted.

Virtual machines. A stronger boundary, enforced by hardware. VM escape, guest to host, is rarer and worth correspondingly more.

Mobile apps. Each app runs in its own sandbox. Compromising one is stage one. Getting to other apps or the system is the escape.

AI agents. Same question, newer setting. When a tool runs generated code, it should be in a box, and the interesting question is exactly the one above: what can it reach if the code turns out to be hostile. Vendors have started saying out loud that the real boundary is operating system isolation and network controls rather than a model's judgement about itself, which is the correct answer and the reason prompt injection is a containment problem rather than a prompting one. It also explains why three vendors shipped agent isolation in one week and drew the line in three different places: escape from what is the whole question.

The four things to keep

A sandbox is a low-privilege box for code you do not trust, plus a checkpoint for anything powerful.

Code execution inside the sandbox is stage one. Serious, not fatal, extremely common.

An escape crosses the boundary, and needs its own separate bug. That is why chains exist and why the pair costs so much more than the parts.

Check the S field in the CVSS vector. S:U stayed in the box. S:C did not. One letter, and it is the answer to the question the headline was vague about.

Sources. The CVE-2026-85046 fields above are from the NVD 2.0 API record and the CISA KEV catalog, read 11 September 2026; scope is defined in the CVSS 3.1 specification. More on that CVE and the deadline attached to it in the KEV catalog stopped being a patch list. On removing whole classes of the memory-safety bugs that make stage one possible, Rust is now tier-1 at Microsoft.