A critical vulnerability in Docker, tracked as CVE-2026-17106 and referred to as “CopyEscape,” allows malicious containers to overwrite files on the host system using the widely utilized `docker cp` command.
This flaw can lead to code execution as the local user and, potentially, as root on Linux systems where copy operations are performed with elevated privileges.
Docker CopyEscape Vulnerability
Researchers at Imperva Threat Research identified the issue in Docker’s container-to-host archive-copy workflow. Docker has confirmed that this vulnerability also impacts `sbx cp`, the copy utility used by Docker Sandboxes. The problem arises when a user attempts to copy files from an attacker-controlled container or sandbox.
Typically, a command like `docker cp container:/file.txt ./file.txt` is designed to write only to the user-specified destination. However, Docker does not perform a simple direct file copy.
Instead, the daemon packages the requested container files into a tar archive, and the Docker CLI then extracts it on the local machine. CopyEscape exploits weaknesses in both parts of this process.
First, an attacker can manipulate the live container’s filesystem while Docker builds the archive. Docker’s archiving routine inspects a path multiple times: first, to determine whether it is a directory, and again to create its tar metadata.
A running container can alter that path between these checks, resulting in an archive that describes contradictory filesystem states.
For instance, if Docker initially identifies an object as a directory, an attacker could replace it with a symbolic link before the archive metadata is completed.
Consequently, the archive could contain a symlink entry followed by a child file that supposedly exists beneath that symlink.
The second weakness occurs during extraction on the host system. While the Docker CLI attempts to validate symlink targets by constructing a path, it ultimately creates the symlink using the original attacker-controlled archive value.
This discrepancy allows an absolute symlink to point outside of the intended destination directory.
When Docker extracts a child entry via that symlink, the operating system resolves the link and writes the attacker’s file to an arbitrary path on the host accessible to the user running `docker cp`. On macOS, this extraction happens on the host rather than inside Docker Desktop’s Linux virtual machine.
An attacker could overwrite crucial files, including shell startup files, SSH configuration, cloud credentials, source code, executables, or LaunchAgent persistence files. A modified shell configuration file could execute malicious commands the next time the victim opens a terminal.
Linux environments face even graver risks, especially when administrators, continuous integration (CI) workers, or automation tools invoke `sudo docker cp`.
Imperva demonstrated that replacing `/usr/bin/runc` with an attacker-controlled script could lead to root code execution during a subsequent Docker operational phase.
The vulnerability does not directly grant root privileges through the Docker daemon; instead, it exploits permissions already granted to the local copy command.
The potential impact is significant for developer systems, CI/CD infrastructure, incident response workflows, and AI-agent sandbox environments. Simply retrieving logs, build artifacts, forensic evidence, or generated code from an untrusted container could trigger an overwrite on the host system.
Docker users are encouraged to upgrade to Docker Engine and CLI version 29.7.2 or later, and Docker Desktop version 4.86.0 or later.
Until patches are implemented, organizations should refrain from copying files from running or untrusted containers, stop containers before retrieval, avoid root-level copy automation, and use disposable virtual machines or low-privilege accounts when analyzing suspicious containers.
Stop new phishing & malware before they compromise your business. Integrate live intel from 15K SOCs around the world
