A critical Docker vulnerability tracked as CVE-2026-17106, also known as CopyEscape, could allow a malicious container to overwrite files on the host machine when a user runs the `docker cp` command.
This vulnerability affects copy-out operations, where Docker retrieves data from a container and extracts it onto the system running the Docker Command Line Interface (CLI).
Docker CopyEscape Flaw
Imperva’s Red Team identified the issue in Docker’s archive-processing path. Although `docker cp` appears to be a simple file-transfer utility, copying from a container to the host involves multiple stages.
Docker’s daemon first packages the requested container content as a tar archive, and then the Docker CLI extracts that archive locally. This means an attacker controlling the source container can influence the archive’s contents, which the local Docker user processes.
CopyEscape exploits two weaknesses in this process. First, a running malicious container can trigger a race condition while Docker scans its filesystem to build the archive.
Docker may initially recognize a path as a directory and decide to explore it, but an attacker can replace that directory with a symbolic link before Docker records its metadata. Consequently, the archive can describe the same path as both a symlink and a directory containing child files.
The second issue arises during extraction. The Docker CLI does not consistently restrict every filesystem operation to the user-specified destination.
A carefully crafted symlink entry could point outside of the designated output directory, while a subsequent child file entry could be written through that link. As a result, a command intended to copy a file to a safe path could inadvertently create or overwrite data elsewhere on the host.
The impact of this vulnerability depends on the privileges of the person or process executing the `docker cp` command. For instance, a developer copying files from a container controlled by an attacker could overwrite important files such as shell startup files, SSH settings, cloud configuration, source code, local binaries, or user-level persistence mechanisms.
On macOS, the Docker CLI performs the extraction on the host rather than within Docker Desktop’s Linux virtual machine, further exposing files in the user’s macOS filesystem.
On Linux, the consequences become more severe if `docker cp` is invoked with elevated privileges. Imperva’s proof of concept demonstrated that it could replace `/usr/bin/runc` with an attacker-controlled script.
A subsequent Docker operation would then execute the modified binary, turning the arbitrary host-file overwrite into root-level code execution.
Notably, the container does not automatically gain root privileges from the Docker daemon; instead, it exploits the authority already granted to the host-side copy process.
This flaw also affects Docker Sandboxes. Docker confirmed that the `sbx cp` command, which transfers files out of isolated sandbox environments, is vulnerable to the same destination-escape condition.
This raises risks in AI agent and coding workflows where users retrieve artifacts from untrusted or compromised sandbox sessions.
To mitigate these risks, Docker users should upgrade to Docker Engine and CLI version 29.7.2 or later, Docker Desktop version 4.86.0 or later, and Docker Sandboxes version 0.38.0 or later.
Until these patches are deployed, organizations should avoid copying data from live untrusted containers, stop containers before retrieving files, avoid using root to run `docker cp` workflows, and use isolated environments when collecting evidence or artifacts from suspected compromised containers.
Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup in your SOC
