Sandbox Escape

Modern programs often run in a shielded area called a sandbox – a sandbox in which code is allowed to romp around without touching the rest of the computer. This area has very tight permissions: for example, it is not allowed to open arbitrary files on the hard drive or communicate with the internet on its own. A sandbox escape is the moment when this protection breaks. The code finds a gap and can suddenly do things that lie outside the sandbox. This makes a sandbox escape one of the most dangerous classes of bugs there is, because it doesn’t just disable a single function, but the entire protective wall.

Why a broken sandbox is so costly

Security people expect individual programs to have bugs. That’s exactly why sandboxes are built: they are the second line of defense. If an attacker opens a website that confuses the browser, they initially only end up trapped in a confined sub-process. The damage stays limited. If this second line falls, there is no third one left.

That’s why companies pay the highest prices for such vulnerabilities. At competitions like Pwn2Own, a browser bug fetches a few tens of thousands of dollars. Only the combination of a bug plus a sandbox escape counts as a complete attack and becomes truly expensive. On the gray market, chains that fully take over a phone go for six to seven figures.

For AI systems, this topic has newly become important. Many chatbots can now write and execute program code themselves, for instance to evaluate a spreadsheet. This code runs in a sandbox because the model cannot be trusted blindly. An escape would mean that a user, through a clever request, gains access to the provider’s servers – and possibly to other users' data.

Which vulnerabilities enable a breakout

A sandbox is never completely sealed, otherwise the program would be useless. After all, it has to report results to the outside, request memory, or draw something on the screen. For all of this there are narrowly defined openings to the operating system. These openings are the attack surface. Anyone who sends a message that the recipient processes incorrectly on the outside can launch foreign code outside the sandbox.

A second path leads through the core of the operating system, the kernel. It manages permissions and decides what a process is allowed to do. A bug in the kernel therefore acts like a master key: whoever exploits it bypasses all rules at once. A third path is misconfigured settings – for example, a folder from the host system that was accidentally mirrored into the sandbox.

A common misconception: a sandbox is the same as a virtual machine, i.e., a completely rebuilt computer inside the computer. A virtual machine separates more strictly, but costs more computing power. However, breakouts occur there too, they’re then called VM escapes. Separation is always a matter of probability, not a guarantee.

Sandboxes in everyday life

The most well-known sandbox is found in the browser. Every tab runs in its own, confined process so that a malicious website cannot read the password file. Apps on a phone are also isolated from one another: a gaming app cannot simply read the chats of a messaging app. PDF viewers and email programs work the same way.

In news reports, you usually encounter this term in connection with urgent updates. When Google or Apple report a vulnerability as “actively exploited,” there is often a chain of several bugs behind it, and one of them is a sandbox escape. That’s exactly why it makes sense not to dismiss such updates for weeks on end.

In AI products, sandboxes appear in the description of coding assistants and so-called agents, i.e., models that carry out tasks independently. Providers then emphasize that tool access runs “isolated” or “containerized.” This is real protection, but not a guarantee. Anyone testing their own AI code should therefore run it in their own sandbox – and not put in any passwords or access keys that have no business being there.