CopyEscape Docker Vulnerability Lets Malicious Containers Overwrite Host Files and Gain Root

A newly disclosed Docker vulnerability, tracked as CVE-2026-17106 and nicknamed “CopyEscape,” allows malicious containers to overwrite files on the host machine and, in certain configurations, achieve full root code execution.

The flaw was discovered by the Imperva Red Team and affects the widely used docker cp command, along with the related sbx cp command used in Docker Sandboxes for AI-agent workflows.

If exploited, CopyEscape allows a malicious container to escape its isolated environment, write or overwrite arbitrary files on the client host, and, under specific conditions on Linux, achieve root-level code execution.

CopyEscape Docker Vulnerability Enables Root Access

The vulnerability lives inside Docker’s archive pipeline, the mechanism that moves files between a container and the host machine. When a user runs a simple command like docker cp container:/path/to/file.txt ./file.txt, Docker does not perform a direct filesystem copy.

Instead, the daemon walks the container’s live filesystem, packages the selected path into a tar archive, and hands that archive to the Docker CLI for extraction on the local machine.

This design assumes two things hold true: the daemon produces a consistent archive, and the CLI keeps every extracted file inside the destination the user chose. Imperva’s researchers found a way to break both assumptions in a single copy operation.

The exploit chains a filesystem race condition with a flawed symlink check. Because Docker locks only its internal state during the archive walk, and not the processes running inside the container, an attacker can manipulate files mid-scan.

Using a timed sequence of directory swaps, the malicious container tricks Docker’s walker into recording a directory, then quietly replacing it with a symlink pointing outside the intended destination, such as /usr/bin.

A validation check in Docker’s extraction code inspects one constructed path but actually creates a symlink using a different, unchecked path from the archive. That mismatch lets the attacker’s files land wherever the symlink points, bypassing the sandbox entirely.

Because docker cp underpins routine tasks like collecting build artifacts, logs, and forensic evidence, the vulnerability directly threatens CI/CD pipelines, developer workstations, and incident-response workflows. Ironically, an analyst pulling evidence from a compromised container to investigate it could unknowingly trigger the exploit.

On macOS, where Docker Desktop runs its daemon inside a virtual machine, the CLI still extracts files locally, meaning attackers could overwrite shell startup scripts, SSH configuration, or LaunchAgents to achieve code execution the next time a terminal opens.

On Linux, if docker cp runs with elevated privileges, as is common in automation, the same write primitive can replace system binaries like runc, converting a file overwrite into immediate root access.

Researchers also confirmed the flaw affects Docker Sandboxes’ sbx cp command, exposing AI-coding-agent environments to the same destination-escape risk when retrieving files from untrusted sandboxes.

Docker has patched the issue in Docker Engine and CLI 29.7.2, Docker Desktop 4.86.0, and Docker Sandboxes 0.38.0, following a disclosure process that began in April 2026 and required multiple extensions to resolve regressions from an earlier fix.

Organizations that cannot upgrade immediately should avoid running docker cp against untrusted or live containers, stop containers before copying files, eliminate sudo docker cp usage, and retrieve suspicious data only through isolated, disposable environments.

The underlying lesson is that archive extraction is itself a security boundary, one that path-string checks cannot guarantee once symlinks and concurrent file changes enter the picture.

[Live Webinar] Join Elastic & UnderDefense to learn how small security teams can unify AI visibility and agentic response into one operating model -> Register Now