Sandbox Escape

Programs running on computers are often confined to an isolated area called a sandbox. The term comes from the sandbox children play in: the program is allowed to play inside it, but it may not touch anything outside. It sees only a few files, may not open foreign folders, and may not access the internet freely. A sandbox escape means that a program overcomes this boundary anyway. Afterward, it can access the real computer, for example reading or altering files, or capturing passwords. The escape is almost always the result of a programming error in the software that guards the sandbox.

Why the last wall matters

Security experts assume that individual protective layers will fail. That’s why several are built one behind the other. A website containing malicious code, for instance, can take over the part of the browser that renders the page. As long as that part sits inside a sandbox, the damage is limited. The attacker is then stuck inside the sandbox and cannot get any further.

A sandbox escape renders this design worthless. A limited problem turns into the complete takeover of the device. This is exactly why companies like Google or Apple pay the highest bounties for such vulnerabilities, sometimes several hundred thousand dollars. Attacks that take over a phone without any action by the user almost always combine an escape with additional flaws.

In the AI field, this topic has taken on new urgency. Language models today write program code themselves and execute it. This code runs in a sandbox, because no one wants to blindly trust a machine. If the executed program escapes, an AI system would suddenly gain privileges it was never meant to have.

How the boundary is drawn and breached

The boundary of the sandbox is not drawn by the software itself, but by a layer beneath it. In most cases, this is the operating system kernel — the core component that manages access to memory, files, and the network. The confined program is only allowed to make a short list of requests to this kernel. Everything else is rejected. A stricter variant is the virtual machine: there, an entire second computer is simulated.

An escape exploits a flaw in precisely this checkpoint. A typical case is a memory error: the program sends a deliberately malformed request, and the kernel then writes data to the wrong location in memory. Anyone who cleverly chooses that location can smuggle in their own instructions. Sometimes a poorly configured rule is enough, such as a folder that accidentally remains shared.

A common misconception is that a sandbox is automatically secure. It is only as good as the boundary it draws. The more requests that are permitted, the larger the attack surface. That’s why the rule applies: as few privileges as possible. Experts call this the principle of least privilege.

Browsers, mobile apps, and AI agents

This topic is encountered most often in the browser. Chrome, Firefox, and Safari separate each open page into its own process with heavily restricted privileges. Mobile apps work the same way: an app is not allowed to look into another app’s photos without permission. This is precisely the separation security updates are referring to when they mention a patched sandbox escape.

In tech news, sandbox escapes usually come up on two occasions. First, at hacking competitions like Pwn2Own, where teams take over a browser live. Second, in attacks involving spyware found on the phones of journalists. In both cases, the escape is the most spectacular part of the chain.

Newly added to the mix are AI products that execute code or act autonomously online. Such systems are called agents. Providers run them in containers — that is, in lightweight sandboxes on rented servers. Anyone evaluating such services should ask how strong this isolation actually is. Because here, an escape doesn’t just put one device at risk, but potentially the data of many customers.