Skip to content
Security & Trust

Docker Sandboxes' copy command let AI agents reach files outside the sandbox

Endor Labs says one planted shortcut and one routine copy could expose a developer's credentials. The fix is version 0.51.0.

W
WebPulse Newsroom
AI-assisted · 4 min read
Share on X LinkedIn
Docker Sandboxes' copy command let AI agents reach files outside the sandbox
In brief
  • Endor Labs found that Docker Sandboxes' sbx cp command let an agent reach host files outside its approved folders. It is tracked as CVE-2026-103916.
  • The flaw needs one copy command from the developer, and Endor Labs says that command is the one the product's help text teaches.
  • Upgrade to version 0.51.0. Docker's first fix, planned for 0.48.0, was later judged incomplete.

A wall is only as strong as the doors nobody listed

Teams adopt AI coding sandboxes to answer one question: what happens if the agent does something it should not? The answer is meant to be that it stays inside the box. Endor Labs has now shown a case where one of the box's own tools carried the damage out.

The lesson here is that isolation is judged by every route out, not by the strength of the wall. A sandbox can hold up well and still leak through a feature that feels like the developer's own action.

What Endor Labs found

Endor Labs published a vulnerability in Docker Sandboxes, tracked as CVE-2026-103916. The researcher says the sbx cp command, which copies files between a sandbox and the developer's computer, does not enforce the folder restrictions that protect the host.

Docker Sandboxes runs each AI agent in a microVM. That is a lightweight virtual machine with its own Linux kernel, Docker daemon, filesystem and network. Developers approve specific folders, usually the project workspace, and those form an allowlist. The allowlist is meant to be the only part of the computer the sandbox can touch.

The researcher found that the allowlist governs one path between host and sandbox, the shared filesystem. The copy command is a second path, and the allowlist is never consulted there.

How the trick works

The agent has read-write access to its workspace. So it can replace a folder there with a symbolic link, which is a shortcut that points somewhere else. Inside the sandbox the shortcut points nowhere, so it does nothing.

The shortcut matters only when the developer runs a copy. The command runs on the host with the developer's full permissions, and it follows the shortcut to wherever it leads. The researcher says the command has one symlink control, the -L flag. That flag checks only the last part of a path.

For copying out of a sandbox, the agent plants a shortcut at the destination the developer is likely to use. The researcher confirmed that the extraction wrote into a directory the sandbox had no grant for. The target's parent folder must already exist, so the write cannot create new parent folders. The researcher notes that still leaves the developer's whole home directory.

For copying in, the agent plants the shortcut in a parent folder instead of the file name. The command then follows it without any flag. Endor Labs says this pulls one file at a time, and the developer has to type a file name that exists.

What an attacker could gain

Endor Labs describes two risks. An agent could read sensitive files, such as cloud credentials and SSH keys. It could also overwrite files on the developer's computer. The researcher says an attacker could steer the agent into this through prompt injection, where hidden instructions in content the agent reads cause it to act.

The write risk is the larger one. The researcher lists files such as ~/.zshrc and ~/.ssh/authorized_keys as places where a planted file could lead to code execution. Endor Labs states plainly that it did not demonstrate that last step. It is reasoning, not a result.

The read risk is narrower, because the developer names the file. But the agent is usually the one proposing the command, and files like ~/.aws/credentials are easy to guess.

Endor Labs also says the developer gets little warning. Copy-out prints nothing on success, and the debug flag adds nothing. The sbx mount command, by contrast, prints the resolved path. Endor Labs scored the flaw 8.2, with scope marked as changed because the impact lands on the host.

A fix that took two tries

Docker first planned a fix in version 0.48.0 for October 13, 2026. Endor Labs says Docker found that fix incomplete after it went live. The finished patch shipped November 3, 2026 in version 0.51.0.

Endor Labs also notes an earlier copy-out bug, CVE-2026-17106, fixed in version 0.38.0. The researcher verified that fix still holds. The new flaw sits in the part it did not check, the extraction root itself.

What to ask your team

Endor Labs says this is the second time in 2026 it has found the same pattern in an AI agent sandbox, after a tool called brig. In both, the main isolation worked and a second route to the host was missed. That is the researcher's observation across two cases, not a measured trend.

Put these questions to the teams running coding agents:

First, are developers on Docker Sandboxes 0.51.0 or later? Second, who has copied files to or from a sandbox workspace since the vulnerable versions? Third, which credentials sit in home directories on machines that run agents? Fourth, do your sandbox reviews list every channel that moves files, or only the mounted folders?

Until developers upgrade, Endor Labs advises treating sbx cp like a command an untrusted party wrote. Resolve the full path first. Prefer folders the sandbox has never had mounted. Be most careful with copies the agent suggested.

A sandbox protects you only as far as its list of exits is complete.

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.