Docker Sandboxes 0.51.0 Closes an sbx cp Path Escape

In brief: Docker released Sandboxes 0.51.0 on November 3, 2026 with a fix for CVE-2026-103916, a high-severity path-handling flaw in sbx cp. Docker's CVE record says versions 0.28.0 through versions before 0.51.0 are affected on macOS, Linux, and Windows. The supported remedy is to upgrade to 0.51.0 or later.

This was not described as a hypervisor or microVM escape. The vulnerable operation happened in a host-side copy path: a malicious sandbox could create or replace a symlink inside its writable workspace, then rely on a later, user-initiated sbx cp operation to read from or write to a host path outside that workspace with the invoking user's permissions. That narrower description is important. It explains both the real impact and the user action required for the documented path.

This article is a source-based impact explainer for people using AI coding agents on development machines. WealthLab reviewed Docker's CVE record, Docker's 0.51.0 release notes and isolation documentation, the NVD entry, and the technical report from finder Peyton Kennedy of Endor Labs. We did not reproduce the flaw, inspect the patch, validate an exploit, or test Docker Sandboxes in production.

The affected range is explicit

Docker's CVE record identifies Docker Sandboxes versions from 0.28.0 up to, but not including, 0.51.0 as affected. It lists macOS, Linux, and Windows as affected platforms and names 0.51.0 or later as the solution. The record was published on November 3, 2026 and assigns the issue CVE-2026-103916.

NVD mirrors the same version range but, at the time of review on November 5, labels the entry “Awaiting Enrichment.” That means the Docker-issued record is the better source for the exact product scope and remedy. The GitHub Advisory Database also displayed unknown affected and patched versions when reviewed, despite linking to Docker's release. Readers should not infer “unknown” product scope from that incomplete aggregation when Docker's own CNA record states the range.

Check the installed client rather than assuming Docker Desktop or another package manager has already delivered the fixed component:

sbx --version

If the result is earlier than 0.51.0 and at least 0.28.0, the version is inside Docker's published affected interval. Follow Docker's supported update path for your platform, then check the version again. Avoid substituting an image tag or the version of the agent running inside a sandbox; the affected code path belongs to Docker Sandboxes and its host-side copy workflow.

Why the microVM was not the whole security boundary

Docker's isolation documentation describes five layers: a hypervisor, network controls, a sandbox-local Docker Engine, workspace isolation, and a credential proxy. Each sandbox runs in its own microVM with a separate Linux kernel. That is a meaningful reduction in exposure compared with running an agent directly on the host.

But a system boundary includes the trusted tools that intentionally move data across it. sbx cp exists to transfer files between host and sandbox. The CVE description says the host side of that operation did not safely confine resolved paths to the shared workspace. A link placed in writable workspace content could therefore influence a later path resolution performed outside the guest.

The practical lesson is not that microVM isolation is useless. It is that a strong guest boundary can coexist with a vulnerable bridge. Clipboard helpers, file-copy commands, credential brokers, port publishing, browser launchers, and IDE integrations all deserve separate threat models because their purpose is to cross or mediate the boundary.

The documented attack requires a second event

The sandbox can alter files and links in a workspace it is permitted to write. According to Docker's description, the security consequence occurs when a user later initiates a copy whose host-side source or destination is influenced by such a link. The copy can then bring a host file into the sandbox or write sandbox-controlled data to another host path with the user's permissions.

This user-initiated step is reflected in Docker's CVSS 4.0 vector, which includes active user interaction. It should not be erased when explaining the issue. At the same time, “requires user interaction” does not mean harmless: copying build output, logs, patches, or generated artifacts is a normal part of an agent workflow, so the required action may look routine rather than suspicious.

Endor Labs' technical report describes testing several symlink positions and explains why a writable workspace can prepare the host-side path resolution even though the symlink target is not reachable inside the microVM. That report supplies useful mechanics, while Docker's CVE record remains the authority for the affected range and official remediation.

What could cross the boundary

The CVE describes two directions of impact. A copy into the sandbox could read a host file outside the intended workspace. A copy out could write sandbox-controlled data to a host path outside that workspace. The exact files at risk depend on the invoking user's permissions and the path used in the later copy.

Potential consequences therefore include confidentiality loss, integrity loss, and disruption, but this advisory does not establish that every affected installation exposed credentials or that any particular file was accessed. Examples such as SSH keys or cloud credentials illustrate why developer-home-directory access can be serious; they are not evidence that such material was taken from a real victim.

Docker's CNA scores the issue 8.4 High under CVSS 4.0 and classifies it as CWE-59, improper link resolution before file access. NVD had not supplied its own assessment at review time. Severity scores help triage, but the most useful local question is whether an affected version handled writable, potentially untrusted workspaces and whether people used sbx cp against paths within them.

Upgrade first; the workaround is deliberately narrow

Docker's solution is direct: upgrade Docker Sandboxes to 0.51.0 or later. The 0.51.0 release notes state that sbx cp now blocks symbolic links in mounted directories from escaping onto other host paths and also blocks Windows workspace escapes through substituted drives.

Docker's CVE record gives a pre-upgrade workaround: do not use sbx cp with a host-side source or destination inside a workspace writable by untrusted sandbox code; use a host-only path for the copy instead. This is a temporary constraint, not an argument for deferring the update. Manually checking one visible link is weaker than using the corrected path handling because parent components, alternate paths, junctions, and concurrent changes can complicate what a path resolves to.

Do not respond by broadly granting the sandbox more host access so that copying seems less special. That would remove a boundary rather than repair it. Likewise, treating the entire home directory as a workspace increases the amount of host data exposed to ordinary workspace semantics and makes least-privilege review harder.

0.51.0 also contains workflow-breaking changes

The security update is bundled with a broader release. Docker says built-in agent names now resolve to published kits, the shell agent uses a published Debian 13 v3 kit, and older v1 or v2 kits cannot be combined with v3 kits. Some existing sandboxes created from embedded Claude or Codex specifications must be recreated before using certain kit or move operations.

Docker advises saving files and unpushed commits before removing those sandboxes. It also notes that first use of the new shell kit requires registry access. These are release-specific migration considerations, not reasons to remain on an affected security version. Back up work, read the full release notes, and plan recreation where required.

The release changes clipboard access and custom-secret behavior too: copying text from a local sandbox to the host clipboard now requires an opt-in setting, and custom secrets require explicit destination hosts. Operators who update only to clear the CVE should still test those intended integrations after the upgrade rather than interpreting a newly blocked flow as a failed security patch.

A safe verification sequence

Verification does not require reproducing the vulnerability. A lower-risk operational sequence is:

1. Record sbx --version and identify whether it falls inside 0.28.0 through 0.50.x.
2. Save workspace changes and unpushed commits, especially where the release notes require sandbox recreation.
3. Install Docker Sandboxes 0.51.0 or later through the supported channel for the host platform.
4. Run sbx --version again and retain that output with the change record.
5. Recreate only the sandboxes required by Docker's migration notes, then verify expected files before deleting old state.
6. Test normal copy-in and copy-out with synthetic, non-sensitive files and paths fully inside the intended workspace.
7. Recheck clipboard, kit, registry, custom-secret, network-policy, and MCP workflows that the 0.51.0 notes say changed.

This confirms the installed version and expected legitimate behavior. It does not prove that every historical workspace was benign or establish whether exploitation occurred. Incident review is a separate task.

Historical review should focus on the bridge, not just agent logs

If an affected installation processed untrusted repositories or external content, first preserve relevant evidence according to the organization's incident process. Then review how sbx cp was used: command history, automation logs, terminal recordings where available, destination paths, timestamps, and unexpected link changes in writable workspaces.

Agent conversation logs alone may be incomplete. The documented consequence depends on a host command and filesystem resolution, so evidence can sit outside the model transcript. Conversely, the mere presence of a symlink is not proof of exploitation; repositories use symlinks legitimately, and attribution requires a timeline that connects workspace state to a copy operation and a resulting read or write.

Rotate credentials only when exposure is plausible under the observed path and permissions or when policy requires precautionary rotation. Do not publish suspected filenames, tokens, or user data while investigating. If production secrets were stored in a developer account reachable by routine tools, the event also exposes a broader secret-placement problem that deserves remediation independent of this CVE.

Who should prioritize this update

Prioritize the update where Docker Sandboxes ran third-party repositories, pull requests, generated patches, package-install scripts, web-derived instructions, or other content the operator did not fully trust. The same applies where agent output was routinely moved with sbx cp and the host user could access deployment keys, signing material, source credentials, or production configuration.

Risk is lower—not zero—where the installed version is outside Docker's affected interval, sbx cp was never used, or all sandbox-writable workspaces and their contents were fully trusted. Version and workflow evidence should drive that conclusion. “The agent was inside a VM” is not sufficient evidence because the advisory concerns the host bridge.

Teams that never deployed Docker Sandboxes are not affected by this product advisory merely because they use Docker containers or another AI coding tool. Other agent runtimes may have analogous boundary-crossing helpers, but CVE-2026-103916 should not be generalized to them without product-specific evidence.

What this changes in AI-agent threat modeling

An agent sandbox should be represented as a set of controlled crossings rather than one box around a process. For each crossing, document who initiates it, which side parses the input, whose permissions are used, how paths or URLs are resolved, and whether writable guest state can influence the trusted side.

File transfer deserves explicit tests for parent-component symlinks, junctions, bind mounts, alternate path spellings, races, archive extraction, and destination replacement. Credential proxies need destination binding and redirect controls. Port publication needs an approval and network-scope model. Clipboard and browser helpers need clear user interaction and trusted executable resolution.

This framing also clarifies defense in depth. The microVM limits direct guest access. Network policy limits destinations. A credential proxy avoids placing reusable secrets in the guest. Correct host-side path resolution protects the file-transfer bridge. No single layer should be credited with guarantees supplied by another.

Questions for a platform or security review

• Which Docker Sandboxes versions are installed across developer machines and CI workers?
• Can inventory distinguish the sbx client from Docker Engine, Desktop, and agent-kit versions?
• Which workflows invoke sbx cp, and are their host-side paths inside sandbox-writable workspaces?
• What host data is reachable by the invoking account even when it is not mounted into the guest?
• Are workspaces reused across trust levels or retained after processing untrusted content?
• Do update procedures include the breaking kit, clipboard, and secret changes documented for 0.51.0?
• Can incident responders correlate host copy commands with workspace link changes without relying only on model transcripts?

Answers should be recorded as local evidence, not assumptions imported from the advisory. The advisory defines the vulnerable mechanism and product range; it cannot reveal how an individual environment was operated.

Evidence boundary and limitations

Docker's CVE record is the primary source for the affected range, platforms, severity, workaround, and fixed version. Docker's release notes establish what 0.51.0 says it changed and document adjacent compatibility considerations. Docker's isolation page describes the intended layers. NVD independently republishes the affected range while noting that its enrichment is pending. Endor Labs provides the finder's technical analysis and reproduction narrative.

WealthLab did not run the proof of concept, compare vulnerable and patched binaries, audit Docker's source, test macOS, Linux, or Windows behavior, or determine whether exploitation has occurred in the wild. CISA's added SSVC data in the CVE record marked exploitation as “none” at publication time; that is a point-in-time assessment, not proof that exploitation is impossible or that the status will never change.

Review date: November 5, 2026. Product versions and advisory metadata can change after publication.

Sources

• Docker CNA record for CVE-2026-103916, published November 3, 2026.
• Docker Sandboxes 0.51.0 release notes, dated November 3, 2026.
• Docker Sandboxes v0.51.0 GitHub release, released November 3, 2026.
• Docker Sandboxes isolation layers, reviewed November 5, 2026.
• NVD entry for CVE-2026-103916, published November 3, 2026; awaiting enrichment when reviewed.
• Peyton Kennedy, Endor Labs: technical report on the sbx cp path escape, published November 3, 2026.

Related WealthLab analysis

• AI security sprints need two boundaries — why authorization and technical containment solve different problems.
• GitHub Copilot local sandboxing — an earlier explanation of the controls around local agent execution.