A newly disclosed Docker vulnerability, tracked as CVE-2026-17106, allows a malicious container to break out of the destination specified by docker cp and overwrite files on the host running the Docker CLI.
The flaw does not automatically give a container unrestricted host control. Instead, it converts a copy-out operation into a host-side write primitive, operating with the permissions of the user or automation process that launches it.
Imperva researchers identified the issue in Docker’s archive pipeline, and Docker lists it as a destination-escape flaw in the docker container cp command.
CopyEscape Docker Flaw
Docker cp does not directly transfer files between two filesystems. For a container-to-host copy, the daemon walks the requested container path, creates a tar archive, and sends that archive to the CLI for extraction.
The container controls the archive’s source data, while the host-side CLI performs the filesystem operations. Security relies on two requirements: the archive must represent a consistent source filesystem, and the extractor must prevent every archive entry from resolving outside the destination.
.webp)
A process running in a malicious container can alter a pathname while Docker builds the archive. Ron Masas showed that Docker may first record a path as a directory, then observe it as a symbolic link when creating archive metadata.
The tar stream can consequently contain a symlink followed by entries that appear to be children of that directory. Those records represent conflicting states of the live filesystem, and the client processes them.
The client-side extraction logic completes the escape. Vulnerable code checks a constructed path while deciding whether a symlink is safe, but creates the link using the original archive value.
An attacker can exploit that mismatch to plant a symlink that resolves to a location outside the chosen output directory. When Docker processes a later child entry, the operating system follows the planted link and writes the attacker-controlled file at an external host path.
.webp)
This creates arbitrary file-write capability within the authority of the account that ran docker cp. On macOS, Docker Desktop’s daemon runs in a Linux virtual machine, but the CLI extracts copied archives on the Mac.
A hostile container could therefore target shell startup files, SSH configuration, source trees, executables, cloud settings, or LaunchAgent persistence files that the local user can modify.
On Linux, impact rises if an administrator, CI worker, or maintenance process invokes docker cp with sudo. Imperva demonstrated that replacing runc through this write primitive could result in root code execution when Docker runs the replaced binary.
The vulnerability also affects sbx cp, Docker Sandboxes’ copy-out command, creating risk when AI agents retrieve untrusted artifacts.
Organizations should upgrade to Docker Engine and CLI 29.7.2 or later, Docker Desktop 4.86.0 or later, and Docker Sandboxes 0.38.0 or later.
Until patches are deployed, avoid copying from running or compromised containers to sensitive systems, avoid sudo-based copy workflows, enforce least privilege in CI, and collect forensic material through isolated virtual machines or disposable accounts.
Detect, investigate, and respond faster with in-browser data inspection from ANY.RUN. Gain complete phishing visibility to strengthen your SOC and reduce MTTR
