Wednesday 12 August 2026, 06:03 PM

CopyEscape explained: The CVE-2026-17106 container-to-host vulnerability in Docker

Learn about CopyEscape (CVE-2026-17106), a critical Docker vulnerability allowing container-to-host arbitrary file writes and root execution via docker cp.

Breaking down the CopyEscape exploit

Anyone who spends time managing infrastructure knows that docker cp is a reflex. We use it to pull build artifacts in CI/CD pipelines. We use it to grab logs when a container crashes. Incident responders rely on it to extract forensic evidence. It is a foundational command for how we interact with containerized environments.

That is exactly why CVE-2026-17106 is such a massive operational headache.

Dubbed CopyEscape, this vulnerability turns a routine administrative action into a root-level host compromise. Discovered by Ron Masas at Imperva and responsibly disclosed to Docker back in April 2026, the flaw targets the basic mechanism of how Docker moves files from a container to the host.

The exploit chain relies on a Time-of-Check to Time-of-Use (TOCTOU) race condition. When you execute a copy command, the Docker daemon scans the container filesystem and generates a tar archive. Meanwhile, the Docker CLI client extracts that archive on the host. If a running process inside the container swaps a target directory for a symlink at the exact right millisecond, the CLI gets confused. It follows the symlink and extracts files outside the intended host directory.

If you are running docker cp with elevated privileges on a Linux host, an attacker can use this arbitrary file-write primitive to overwrite /usr/bin/runc. The result is immediate root-level code execution on your host machine. A working Proof-of-Concept is already floating around GitHub via an entity called HackSpeak.

Market impact and the AI tooling dilemma

Looking at this from an industry perspective reveals a clear shift in where the real security risks lie. We spend a lot of time worrying about external network perimeters. We spend less time thinking about the administrative tools our automated systems use every single day.

The most fascinating and troubling aspect of CopyEscape is its impact on the booming AI agent market.

Right now, countless Bay Area startups are building AI agents that write and execute code. To do this safely, they isolate the AI workflows using tools like Docker Sandboxes. The agent generates code, runs it in a sandbox, and the system uses sbx cp to retrieve the output.

CopyEscape directly impacts the sbx cp command. This means a malicious prompt could trick an AI agent into generating an exploit payload that breaks out of the sandbox the moment the host system tries to retrieve the results. For startups selling secure AI execution environments, this vulnerability breaks their core product promise. The market demand for AI sandboxing is massive, but the underlying infrastructure is clearly still fragile. Docker recognized this threat vector and issued a specific patch for Docker Sandboxes version 0.38.0 earlier in August.

Winners and losers

Every major vulnerability creates a ripple effect in the tech ecosystem.

The clear losers here are organizations relying on legacy CI/CD automation that blindly pulls artifacts from running containers. Traditional incident response playbooks also take a hit. If your first step during a suspected breach is to run docker cp to grab forensic data from a live container, you might accidentally trigger the exact payload the attacker left behind to compromise your host.

The winners are the vendors pushing zero-trust infrastructure and least-privilege enforcement. Companies advocating for rootless Docker adoption now have a perfect case study to bring to their enterprise sales calls. Imperva also scores a significant brand win here. Their Red Team found a highly complex bug and their coordinated disclosure gave Docker months to patch it before going public. That is how the security ecosystem is supposed to work.

The operational fix

Docker has rolled out patches across the board. You need to update Docker Engine and CLI to version 29.7.2 or later. Docker Desktop users need to move to 4.86.0. If you are building AI tools, ensure Docker Sandboxes is updated to at least 0.38.0.

If you cannot patch immediately, there is a highly effective operational mitigation. The entire exploit relies on a running process inside the container winning a race condition against the Docker daemon. If you simply stop the container before running the copy command, you completely break the exploit chain.

Going forward, we need to rethink how we handle archive extraction across trust boundaries. Moving data out of an untrusted environment will always carry risk. We just need to ensure our automated pipelines are built to recognize that reality.