CopyEscape: A Simple docker cp Opens the Door to Container Escape

CVE-2026-17106 turns docker cp into a container escape vector. Discovered by Imperva, it allows a malicious container to overwrite files on the host and achieve root code execution when the command runs with elevated privileges.

The docker cp command, used millions of times a day to pull logs or artifacts from containers, hides a flaw that inverts the trust relationship between host and guest. On August 12, 2026, industry sources confirmed details of CVE-2026-17106, dubbed CopyEscape: a race condition in Docker's tar stream allows a compromised container to rewrite arbitrary files on the host filesystem, with potential escalation to root when the command runs with elevated privileges. The vulnerability, discovered by the Imperva Red Team, turns routine forensic operations — copying a suspicious log file — into attack vectors.

Key Takeaways

TOCTOU Mechanism: The container alters a symlink between the directory scan and tar header creation, tricking the CLI client into extracting files outside the destination directory.
Differentiated Platform Impact: On macOS, the overwrite occurs directly on the native host, not in the daemon's Linux VM; on Linux with sudo docker cp, replacing /usr/bin/runc leads to root code execution.
Extended Scope to AI Sandboxes: The sbx cp command in Docker Sandboxes shares the same vulnerable logic, exposing environments where automated agents process untrusted code.
Patches Available for Days: Docker released Engine/CLI 29.7.2, Desktop 4.86.0, and Sandboxes 0.38.0 (August 6, 2026), but disclosure begun in April 2026 suffered multiple extensions due to regressions.

The Innocuous Command That Breaks the Boundary

The Imperva Red Team opened their research with a mundane line: docker cp container:/path/to/file.txt ./file.txt. That command, as the team documented, is the starting point of an attack that upends Docker's security architecture. The problem lies not in the daemon, which typically runs with elevated privileges, but in the CLI client and the github.com/moby/go-archive library v0.2.0.

The docker cp pipeline does not transfer files directly: the daemon serializes the container's contents into a tar archive, and the client deserializes it on the local machine. This separation between who builds the archive (the container, under attacker control) and who extracts it (the client, with the permissions of the user who launched the command) is the crux of the issue.

Ron Masas of Imperva, quoted by CyberPress, summarized the mechanism: a process in the malicious container can alter a pathname while Docker builds the archive. The race condition exploits the temporal gap between path verification and its actual creation on the destination filesystem.

"The attacker controls the container and its files, the CLI supplies access to the host filesystem" — Imperva Red Team

How the Race Condition Works in Detail

The source code analyzed by Imperva shows a classic time-of-check to time-of-use pattern. The walker traversing the container's filesystem initially records a path as a valid directory. Between that recording and the subsequent call to addTarFile, which builds the tar archive header, a process in the container replaces that directory with a symlink. The result is a tar archive containing both representations: the original, verified one, and the manipulated one.

At extraction time, the CLI client builds a destination path and verifies its validity, but then creates the symlink using the original value present in the archive. The checked path and the path actually written diverge. The extractor, convinced it is operating inside the authorized directory, instead follows the symlink planted by the attacker to any point on the filesystem.

On macOS the consequence is particularly insidious: the Docker Desktop client extracts files directly onto the host's native filesystem, not into the Linux VM where the daemon runs. A user copying a suspicious log for local analysis could find system files overwritten in their home directory.

From Overwrite to Root: The Chain on Linux

The proof-of-concept validated by Imperva on Docker Engine 29.6.1 (Linux) and Docker Desktop 4.81.0 (macOS) demonstrates that arbitrary overwrite is only the first rung. On Linux systems where docker cp runs with sudo, the attacker can target /usr/bin/runc directly, the container runtime underlying Docker.

The PoC replaces the runc binary with an attacker-controlled script. When a subsequent Docker operation — even something as mundane as starting a new container — invokes runc, it executes the compromised binary with root privileges. The Imperva Red Team emphasized a crucial technical point: the exploit does not obtain root from the Docker daemon. The copy already had sufficient authority to replace runc; the later execution converts that write capability into root code execution.

"The exploit did not obtain root from the Docker daemon. The copy already had enough authority to replace runc, and the later execution converted that file write into root code execution" — Imperva Red Team

This distinction has significant practical consequences: compromising the daemon, already protected by isolation mechanisms, is unnecessary; it suffices that an administrator runs sudo docker cp from a container they don't know is malicious. In automated CI/CD pipelines where scripts regularly perform this operation without human intervention, the exposure window is maximal.

The Forensic Trap and AI Sandbox Risk

Imperva's article explores a scenario bordering on bitter irony: a security analyst attempting to investigate a suspicious container by copying its logs unwittingly becomes the vehicle for their own compromise. The standard forensic operation — extracting evidence for offline analysis — triggers the payload. The container need not communicate externally, requires no network exploit: the escape occurs through the data extraction channel opened by the investigator.

The risk extends to a rapidly expanding sector. Docker Sandboxes, the platform for running AI agents in isolated environments, shares the same copy logic with the sbx cp command. Sandboxes version 0.38.0, released August 6, 2026, explicitly fixes the same "destination-escape flaw in sbx cp copy-out" under CVE-2026-17106. In environments where coding agents automatically generate and execute code, the possibility that a malicious artifact escapes the sandbox via a copy-paste routine represents an attack surface with risk profiles still being defined.

What to Do Now

Update Immediately Docker Engine/CLI to version 29.7.2, Docker Desktop to 4.86.0, and Docker Sandboxes to 0.38.0, per vendor releases.
Audit sudo Usage in scripts and procedures that run docker cp: execution with elevated privileges is a necessary condition for root escalation on Linux.
Review CI/CD Pipelines that automate artifact extraction from containers: replace docker cp with export mechanisms that do not pass through the client's tar deserialization, where possible.
Inspect System Logs for docker cp executions on untrusted containers, especially in forensic environments where the source container is already suspect.

The CopyEscape disclosure began in April 2026 and went through multiple extensions, according to CyberSecurityNews, to resolve regressions in candidate patches. This delay in stabilizing the fix suggests the go-archive component has implications broader than the single documented CVE, though the dossier does not specify whether other Docker commands depending on the same library are affected.

FAQ

Is a Compromised Container Enough to Be Vulnerable?

Yes: the container must be under attacker control, but requires no special privileges inside the container itself. The vulnerability exploits the mismatch between who builds the archive (the container) and who extracts it (the client).

Is My Docker Desktop on Mac at Risk Even Without sudo?

Yes: on macOS extraction occurs directly on the host filesystem. No sudo is needed to overwrite files in the user's home directory, though root escalation still requires additional conditions not detailed in the dossier.

Why Is the CVE Record Still Reserved?

The CVE-2026-17106 record shows as reserved on cve.org at time of publication. The CVSS score and full CNA details are not yet populated, though the identifier is confirmed by primary sources.

Docker's architecture has always assumed the daemon was the perimeter to defend, relegating the client to a passive role. CopyEscape proves the chain of trust breaks elsewhere: the moment a tar archive crosses the boundary, the extractor becomes vulnerable to the builder. For forensics, developers, and AI sandbox operators, the lesson is that no command is too mundane to be examined with suspicion.

Sources

Information verified against cited sources and current as of publication.

Sources

Sources and references