Live › vulnerability › CVE-2026-103916
Docker Sandboxes' sbx cp command does not keep host-side paths confined to the shared workspace. A malicious sandbox can plant a symlink so a later user-initiated copy reads or writes host files outside the workspace, using the invoking user's permissions.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-11-03 17:21 UTC. All times on this page are UTC.
Teams that run Docker Sandboxes and use sbx cp to move files between a sandbox and the host. The risk needs a sandbox that is malicious or compromised and a later user-initiated copy against its workspace. Teams not using Docker Sandboxes or sbx cp are not affected.
| Product | Ecosystem | Affected | Fixed in |
|---|---|---|---|
| Docker Sandboxes (sbx) | vendor | >= 0.28.0, < 0.51.0 | 0.51.0 |
sbx version; versions from 0.28.0 up to but not including 0.51.0 are in the affected range reported in the CVE record (as relayed by hol.org; Docker's release notes do not name the CVE).sbx cp against a sandbox you do not fully trust. Before upgrading, avoid sbx cp on sandboxes that may be compromised and check the workspace for unexpected symlinks pointing outside it.Upgrade Docker Sandboxes (sbx) to 0.51.0 or later; 0.51.0 release notes: 'sbx cp blocks symbolic links in mounted directories from escaping onto other host paths.'
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
Docker Sandboxes sbx cp does not safely confine host-side paths to a shared workspace. A malicious sandbox can create or replace a workspace symlink so that a later user-initiated copy reads a host file outside the workspace into the sandbox or writes sandbox-controlled data to a host path outside the workspace with the invoking user's permissions.
This page as .md · .json · in your agent: get_signal("CVE-2026-103916")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.