Docker Sandboxes' sbx cp Followed Workspace Symlinks Straight Onto the Host

A high-severity flaw in Docker Sandboxes lets an AI coding agent turn a routine host copy into a path outside the workspace allowlist—reading secrets or planting files with the operator’s permissions. CVE-2026-103916 was published in researcher detail on November 3, 2026 by Endor Labs’ Peyton Kennedy. The product is Docker’s sbx CLI for running agents such as Claude Code, Codex, and Gemini CLI inside microVMs. CVSS 3.1 is 8.2 (AV:L/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H); CVSS 4.0 is listed at 7.3. The CWE is CWE-59 (improper link resolution before file access). The fix shipped in v0.51.0 the same day after an earlier 0.48.0 attempt proved incomplete. Public CVE summaries describe affected builds from 0.28.0 through versions before 0.51.0.

Docker Sandboxes isolates each agent in a microVM with its own kernel, Docker daemon, filesystem, and network. Developers explicitly share project folders into the guest over virtio-fs; that share is the documented allowlist. The bug sits on a second channel: sbx cp, which moves bytes between host and sandbox through ordinary host filesystem I/O performed by the CLI as the operator. That path never consulted the allowlist. The CLI resolved symlinks in the paths it was given and acted on the resolution. The sandbox, with read-write rights on the workspace, can plant those links.

Four symlink seats, three left open

Kennedy mapped four places a symlink can sit on a copy. Copy-out destinations follow links by default at both the last component and parent components, and the -L flag does not gate them. Copy-in sources follow parent components by default; only a leaf symlink on the source is gated by -L. Three of four seats are therefore open to an agent that can rewrite the workspace. A trailing slash or vendor/. form collapses lexically back to the gated leaf case, so whole-directory pulls are not a single command—but one guessable filename at a time is enough for credentials and keys.

The write path is stronger. The agent plants a symlink at a destination the operator is likely to copy into—for example a results/ folder under the workspace pointing at ~/.ssh or another home path whose parent already exists. The operator then runs the exact form sbx cp --help teaches. On success the CLI prints nothing; the extraction root has already resolved through the link. Kennedy confirmed overwrite of a canary, whole trees, and relative ./results/ forms. The write cannot create missing parents, but that still leaves the operator’s home directory. Escalation via ~/.zshrc, authorized_keys, git hooks, or node_modules binaries is reasoned as the next step; it was not demonstrated in the write-up.

The read path plants the link one component left of a plausible filename. Copying what looks like a workspace file pulls the host target into the guest. Error text can also leak the resolved host path when a destination is missing. Baseline checks in the report show that even mounting the host virtio-fs share as root inside the guest cannot reach an ungranted canary—so the allowlisted channel held while sbx cp did not.

Second copy-channel bug of the year

Containment added for an earlier archive-path escape, CVE-2026-17106 (fixed in v0.38.0), still held for paths inside the archive. It did not check the extraction root itself or the copy-in source path. Docker initially targeted a fix for October 13, 2026 in 0.48.0; after that landed incomplete, the finalized patch arrived November 3 as 0.51.0. Kennedy’s suggested remedies—secure-join the copy-out destination root (the binary already links cyphar/filepath-securejoin), apply -L rules to every source component, and print resolved paths on success the way sbx mount does—match the architectural lesson: the isolation primitive worked; the operator-looking second path was left out of the security model.

Until hosts are on 0.51.0 or later, treat any sbx cp that touches a workspace path the sandbox can rewrite as hostile. Resolve the full path yourself before copying, prefer directories the sandbox has never mounted, and be most suspicious of copies the agent proposed. The allowlist story for Docker Sandboxes is only as strong as every channel that crosses the host boundary—not just the one with the documented mount policy.