Brief · Builders

Docker Sandboxes' Copy Command Walked Right Out of the Sandbox

By alkizz · Nov 4, 2026

Docker Sandboxes is Docker's tool for running AI coding agents like Claude Code, Codex and Gemini CLI in their own microVM, so the agent only sees the folders you hand it. On Nov 3, Peyton Kennedy at Endor Labs published CVE-2026-103916, which shows that the sandbox's own copy command, sbx cp, ignores that boundary. An agent plants a symlink in its workspace, you run an ordinary copy, and the file lands somewhere on your machine the agent was never supposed to touch. Docker fixed it in v0.51.0, released Nov 3, so the main move is to update.

What's broken

According to Endor, Docker Sandboxes has two ways to move files between your computer and the sandbox. The shared folders go through an allowlist, and that part held up in Endor's testing. Even mounting the whole host share as root inside the guest couldn't reach Endor's test file. But sbx cp is a second channel. It runs on your side as you, "with the operator's full permissions," and Endor says "The allowlist is never consulted."

The trick is that the agent controls the workspace. It can swap a folder for a symlink pointing anywhere on your machine. Inside the sandbox that link points at nothing, so it looks harmless. It only does something when sbx cp resolves it on your side during a copy you run.

The command has one symlink guard, the -L flag, and Endor says it covers only one of the four places a symlink can sit. "Three of the four positions are open."

That gives the agent two moves:

• Write. You copy a file out to what looks like a folder in your workspace, and it lands wherever the agent's link points. Endor demonstrated it overwriting a test file outside the workspace. The one limit is that the target's parent folder has to already exist, which Endor notes "still leaves the operator's entire home directory." It lists ~/.zshrc, ~/.ssh/authorized_keys and .git/hooks as targets that would turn the write into code running as you. Endor says plainly that it didn't demonstrate that step and is "stating it as reasoning rather than as a result."
• Read. You copy what looks like a workspace file into the sandbox, and a link one folder up pulls in a real file from elsewhere on your machine instead. It's one file at a time, and you have to type a filename that exists, but against ~/.aws/credentials or an SSH key, Endor points out, "naming the file is not an obstacle."

The part I like least is how quiet it is. Endor says copy-out "prints nothing on success" and shows no resolved path, so even if you're watching, there's nothing to see. And the copy is often one the agent suggested in the first place. Endor also says an attacker could steer an agent into doing this through prompt injection, meaning instructions hidden in content the agent reads.

Severity, and the numbers don't all match

Endor scores it CVSS 3.1 8.2 (High) and CVSS 4.0 7.3. Docker, which assigned the CVE, gives it a CVSS 4.0 score of 8.4 (High) in the NVD record. The scores differ, but everyone agrees it's High. Docker's CVE record lists affected versions as 0.28.0 up to, but not including, 0.51.0, and CISA's SSVC entry on it says exploitation "none." I haven't seen any report of this being used in the wild.

The fix took a couple of tries. Endor says Docker first planned to ship it in 0.48.0 on Oct 13, but "after the initial patch was live, the Docker team determined the fix was incomplete," and the finished fix came in 0.51.0. Docker's release notes for 0.51.0 say sbx cp now "blocks symbolic links in mounted directories from escaping onto other host paths," and on Windows it also blocks escapes "through substituted drives." The 0.50.0 notes from Oct 26 also list a related sbx cp symlink fix for workspaces reached through an alternate host path.

It's also not the first sbx cp bug. Endor says CVE-2026-17106, fixed in v0.38.0, was an earlier copy-out escape, and that fix still held. This one just lives somewhere the earlier fix didn't check.

Why this one matters

Nothing here was a microVM escape, and Endor says the isolation itself worked. The failure was what Endor calls "a second path to the host that the security model did not account for," and it calls this the second time in 2026 it has found "the same shape of bug in an AI agent sandbox." I think that's the useful lesson. A sandbox is only as tight as every pipe that runs through it, and the convenience features (copy, clipboard, mounts) are usually the ones nobody threat-models, because they look like your own action.

What to do:

• Update Docker Sandboxes to v0.51.0 or later.

  • Why: Docker's CVE record lists 0.28.0 up to 0.51.0 as affected, and the 0.51.0 release notes carry the sbx cp symlink fix.
  • How: run sbx version to see what you have, then update through however you installed it. Read the 0.51.0 breaking changes first, because sandboxes made from older built-in Claude or Codex specs keep running but have to be recreated before some commands work. Save files and unpushed commits before you remove a sandbox.

• Be careful copying anything out of a sandbox, even after you update.

  • Why: the agent controls every path inside its workspace, and Endor's advice is to "treat sbx cp with the same care you would give a command an untrusted party wrote," and to "be most suspicious of copies the agent proposed."
  • How: copy to and from host folders the sandbox has never had mounted. Docker's workaround in the CVE record says the same: don't point sbx cp at a host path "inside a workspace writable by untrusted sandbox code," and use "a host-only path for the copy instead." If you have to use a workspace path, run realpath on it first and check it stays inside the workspace. Endor notes that checking only the last part of the path isn't enough.

• Treat what you copied out as untrusted until you've looked at it.

  • Why: the write bug is fixed, but an agent can still put anything it likes inside the files themselves, and Endor's own impact list includes things like a .git/hooks script or a binary under node_modules.
  • How: my suggestion: copy agent output into a scratch folder, look at what's there, and only then move it into a real project. Never copy straight into your home directory or a repo you run hooks in.

Sources

• Endor Labs: Docker Sandboxes vulnerability lets AI agents access sensitive files outside their sandbox (CVE-2026-103916) (Peyton Kennedy, Nov 3, 2026)
• Docker: Docker Sandboxes release notes (0.51.0, Nov 3, 2026; 0.50.0, Oct 26, 2026)
• NVD: CVE-2026-103916
• TrackCVE: CVE-2026-103916 (Docker's solution and workaround text)

← All briefs