- Endor Labs found that an agent in brig's sandbox could plant a symlink that exposed other host directories on a later run. Brig 0.3.0 fixes it.
- The isolation itself held. Brig guarded one mounted folder with four checks and the other with one, and both fed the same host-side operation.
- Upgrade to brig 0.3.0, and ask whether every route into your agent tooling shares one set of controls.
The wall held. The door beside it did not.
Companies now let AI coding agents read and edit their code. A sandbox is meant to keep the agent in one room, with access only to the project you point it at. Endor Labs researchers found a way for an agent to reach beyond that room without breaking the wall at all.
The tool is brig, which runs agents in sandboxes. Endor Labs tracks the issue under two identifiers: GHSA-wp6x-29qx-fpr7 and ENDOR-VUL-2026-1809. Version 0.3.0 contains the repair. Endor Labs says the sandbox's hardware-level isolation was never the problem.
The lesson for leaders is plain. A sandbox is only as strong as the least-checked path that feeds it. This is a single product's bug, but any security team can test its own tools for the same pattern.
How a planted shortcut becomes host access
Brig mounts two things into the sandbox. One is a working directory brig creates and controls. The other is the project folder the operator names. Endor Labs reports that brig guarded the first with four checks. The second got one: refuse a path that resolves to the root of the disk.
Brig never resolved the project path itself. It handed the text to the virtual machine monitor, the host component that builds the sandbox, and that component worked out the real destination on the host, outside the sandbox. The agent has read-write access to the project. So it can swap a subfolder for a symlink, a shortcut that points to any other directory on the machine.
The shortcut does nothing in the run that plants it. Inside the sandbox it points nowhere. The trap springs on a later run, when an operator narrows the run to that subfolder. Operators do this routinely to focus an agent on one part of a monorepo, one repository that holds many projects. Brig then follows the link on the host and mounts the target read-write.
What the agent can reach
Endor Labs confirmed reads and writes on two setups. One was macOS 15 on arm64 using brig 0.2.0 on the microVM backend. The other was Ubuntu 24.04 on arm64 using nerdctl over containerd. The result was the same on both.
On Linux, the researcher pointed the link at the host user's home directory. The sandbox's own mount listing then showed that home folder inside the project path. The researcher read a host SSH private key the sandbox was never meant to see. The researcher also read brig's session index and wrote files back to the host.
The reachable set is wide. It includes ~/.ssh, ~/.aws, the GitHub CLI's hosts.yml file, brig's own state and the guest home of every other session. If an attacker can write to ~/.ssh/authorized_keys or a shell startup file, that becomes code execution as the host user.
This matters for how teams reason about risk. Brig's documentation relies on a narrow blast radius: one guest home and one token. Endor Labs argues this flaw removes that radius, so an agent holding a token scoped to one repository could reach every credential on the machine. Blocking or limiting the network does not change this. The path is a shared folder, not a network connection.
One limit is worth stating. The researcher pointed a link at /proc and saw a write to a kernel setting succeed. They did not fire a payload, because their test host was nested. They report that step as inferred, not demonstrated.
Two paths, one dangerous operation
The maintainers filed the bug under CWE-59, the weakness category for following a link without resolving it first. Endor Labs agrees that brig acted as a confused deputy: a trusted program tricked into using its authority for someone else. This is not a hypervisor or guest-kernel escape. Both held.
The deeper cause was an assumption. A code comment reasoned that the project folder was named by the user, so nobody could swap it. But the sandbox holds that folder read-write for the whole session. The actor the workspace check defends against was also present at the project folder.
This is an easy pattern to miss. Teams harden the path they thought of and leave a second path to the same operation lightly defended. Brig had both a careful control and a weak one, and both ended in the same place: a host path handed to another process to resolve.
What the fix and the workaround do
Brig 0.3.0 opens the project path one component at a time. It refuses every symlink below the first directory the user can write, and it checks after each open that it got what it inspected. It refuses even links the operator created, because brig cannot tell them from planted ones. The run summary now shows where the path actually led.
If you cannot upgrade, Endor Labs advises resolving the project path yourself and naming the resolved directory. Checking only the last component is not enough, since a link can sit at any point in the path.
Questions for your team
First, does anyone run brig, and is it on 0.3.0 or later? Second, which credentials sit in home directories on machines where agents run? Third, when your tooling has two ways to reach one sensitive operation, do they share a single implementation of the checks?
Endor Labs called its exchange with the brig maintainers "a genuinely good vendor interaction." The maintainers even proposed dropping the label "sandbox escape" because the isolation did not fail. That precision helps buyers. The boundary held, and the control around it did not.
A sandbox is a promise about the room. The risk lives in everything that carries paths into it.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Endor Labs.
