Docker Sandboxes vulnerability lets AI agents access sensitive files outside their sandbox (CVE-2026-103916) | Endor Labs

What it is

CVE-2026-103916 is a flaw in sbx cp, the file-copy command of Docker Sandboxes (microVM-based sandboxes for AI coding agents such as Claude Code, Codex and Gemini CLI). Endor Labs' researcher found it. sbx cp does host-side file I/O as the operator, without consulting the folder allowlist that normally limits what a sandbox can reach. A sandboxed agent can therefore make one ordinary operator copy read or overwrite files anywhere the operator's account can reach. Fixed in 0.51.0, released 3 November 2026.

How it works

The agent has read-write access to its workspace, so it can plant a symlink there. Inside the guest the link dangles and does nothing. On the host, sbx cp resolves it and acts on the target.

The -L flag is the only symlink control, and it checks only the last path component. A symlink can sit in four positions, and three are open:

• Copy-out (write): a symlink at the destination directory, or one level above it, becomes the extraction root. The extractor contains paths inside the archive but never checks the root itself. The page shows this overwriting a file outside the workspace, and -L has no effect on the destination side.
• Copy-in (read): a symlink at a parent component, such as work/vendor -> secret, makes sbx cp ~/.../work/vendor/notes.txt repro:/tmp/in/ pull the host file into the sandbox. A link at the leaf is correctly copied as a link.

The earlier CVE-2026-17106 (fixed in v0.38.0) covered paths inside the archive. Its containment still works, but this bug lies outside what it checks.

Preconditions / Affected

• The operator must run one sbx cp that touches an agent-influenced path. This is the form sbx cp --help teaches, and the agent often proposes it itself.
• A prompt injection is the stated route for getting an agent to plant the link.
• Write needs the target's parent directory to exist. Read needs a guessable filename, and the page names ~/.aws/credentials and ~/.ssh/id_ed25519 as such targets. Read is one file at a time, since trailing-slash forms collapse back to the gated leaf case.
• Copy-out prints nothing on success, and the debug flag adds nothing, so the operator sees no warning.
• The write is reached through the operator's whole home directory. The page reasons that ~/.zshrc, ~/.ssh/authorized_keys, git hooks or a core.pager setting would turn it into code execution, but says it did not demonstrate that.
• CVSS 8.2, with Privileges Required Low, User Interaction Required and Scope Changed.

What to do

Upgrade to Docker Sandboxes 0.51.0 or later. The 0.48.0 patch, scheduled for 13 October 2026, was found incomplete after release.

Until upgraded, resolve the host path yourself before any copy and confirm it stays inside the workspace:

realpath ~/sbxlab/repro/work/results     # must stay inside the workspace

Checking only the last component is not enough, because the link can sit at any component. Prefer directories the sandbox has never had mounted, and be most suspicious of copies the agent proposed.

The researcher also suggested containing the copy-out root (the cyphar/filepath-securejoin library is already linked into the binary), applying the -L rule to every component of the copy-in source, and printing the resolved path on success.

Caveats

The page does not show what 0.51.0 changed in detail or confirm which of the three suggestions Docker adopted. The page's reproduction ran on a macOS-style /Users path layout. A leaked error message (Can't add file /Users/me/... to tar) shows resolved host paths on copy-in failure.