A newly documented Docker weakness shows how a routine file-copy operation can undermine the boundary between a container and its host. Tracked as CVE-2026-17106 and nicknamed CopyEscape, the flaw allows a malicious container to influence the archive produced by docker cp, potentially causing files to be written outside the directory selected by the user.

The practical impact depends on the authority of the person or automation running the command. A developer could lose control of shell configuration, SSH settings, cloud credentials or source files. If an administrator or continuous-integration job invokes the copy operation with elevated privileges, an attacker may be able to replace sensitive system files and ultimately execute code as root.

How a simple copy crosses the boundary

Docker does not transfer a requested file directly from a container to the host. The daemon packages the content into a tar archive, and the local command-line client extracts that archive with the permissions of the user who initiated the copy. That two-stage process gives an attacker who controls the source container an opportunity to manipulate how paths are represented.

Researchers at Imperva described an exploit chain with two parts. First, a time-of-check to time-of-use race lets a running container replace a directory with a symbolic link while Docker is traversing its filesystem. The resulting archive can present the same path inconsistently—as a normal directory in one place and a link in another.

Second, affected extraction code does not reliably keep later writes inside the intended destination after resolving filesystem links. A carefully arranged archive can therefore redirect a subsequent file entry to another location on the host. The user still sees what appears to be a normal copy command, while the actual write lands somewhere else.

Elevated automation raises the stakes

The bug does not directly hand a container control of the Docker daemon. Instead, it borrows the privileges already held by the copy process. This distinction matters because many build, support and incident-response workflows run Docker commands through sudo or from highly privileged service accounts.

In a proof of concept, the researchers replaced the host’s /usr/bin/runc binary with an attacker-controlled script. When Docker later called the modified runtime, the payload executed as root. On macOS, extraction occurs on the local computer even though Docker Desktop places containers inside a Linux virtual machine, meaning user files on the Mac can still be exposed.

Docker Sandboxes are also affected through the related sbx cp command. That broadens the concern to AI coding and agent workflows that retrieve artifacts from untrusted or semi-trusted execution environments.

Updates and temporary safeguards

Docker Desktop 4.86.0 fixes the destination escape, while Docker Sandboxes 0.38.0 addresses the corresponding sandbox path. The corrected moby/go-archive component is version 0.3.0; earlier releases are affected. Organizations should bring Docker Desktop, Engine and CLI installations to current patched versions rather than updating only one layer.

Until upgrades are complete, security teams should reduce opportunities for a hostile live filesystem to shape an archive:

• Avoid copying content from untrusted or potentially compromised running containers.
• Stop a container before retrieval when operationally possible, which disrupts the demonstrated race.
• Remove sudo and root service accounts from artifact-collection jobs unless strictly necessary.
• Handle suspicious container output inside disposable virtual machines or isolated analysis systems.
• Review CI pipelines and agent frameworks for automated copy operations against externally supplied workloads.

Archive extraction is a security boundary

CopyEscape is another reminder that container isolation can be weakened by the tools used around it. Even if a workload cannot directly access the host, packaging and extracting its files creates a new parser and path-resolution boundary. Defenders should treat output from an untrusted container like any other hostile archive, with minimal privileges and a controlled destination.

Teams that use containers for malware analysis, untrusted builds or AI-generated code should prioritize the update. Those environments are precisely where a seemingly harmless request to retrieve a report or build artifact may give attacker-controlled content a bridge back to the host.

Source: Cyber Security News, based on research and vendor guidance cited in its report.