Docker's CopyEscape: a docker cp destination escape and what I checked on my swarm

CopyEscape, CVE-2026-17106, is a destination escape in docker cp that lets a running container write files outside the destination you pick ¹. Docker Desktop 4.86.0 carried the fix on August 10, 2026 ². A container can race the copy and plant a symlink that the CLI follows past the chosen destination ¹. The write lands with the permissions of whoever ran the copy, so the container never has to break the daemon. I read the disclosure the same week it landed, then I went through my swarm the way I go through any container runtime advisory.

How the copy breaks

A copy from a container is a two-step operation. The daemon walks the container filesystem and turns the path into a tar archive, then the CLI on your machine extracts that archive ¹. That split is the opening. The container decides what goes into the archive, and your CLI does the writing, under your permissions.

The researchers broke both sides of that split in a single copy ¹. The daemon walks with a directory walker that records an entry type, then looks the same path up again a moment later to build the tar header. Between those two lookups, a process inside the container can rename the entry away and leave a symlink behind ¹. The walker still reads the old directory type, so it descends and adds a child through a name that is now a link. The resulting archive describes two moments in the source filesystem at once, one entry for each.

That archive on its own should not matter, because the client controls the extraction and can reject the dangerous sequence. This one gets through, and the weakness is the containment check. It validates one path while the kernel call uses another, so a path that looks like it stays inside the destination lands where the link points ¹. The proof of concept writes a shell script over /usr/bin/runc, and the next container operation runs that replaced binary as root ³.

What it does to a node

My swarm runs Docker Engine on a set of Linux hosts rather than Docker Desktop, so the fix that applies to me is the Engine release instead of the Desktop build. The extraction fix shipped in Docker Engine and CLI 29.7.0 alongside go-archive 0.3.0 on July 30, 2026 ¹. Docker Desktop 4.86.0 carried the same fix on August 10 ².

The impact on a node depends on who runs the copy. When an ordinary user runs the copy, it reaches the files that user can write. When sudo runs it, it reaches the system paths, and that is the step that turns a file write into host takeover. On my nodes the daemon and the CLI share the host ¹, the same layout the Linux proof of concept runs against ³.

What I verified

I checked the version on every swarm host first. Every node below 29.7.0 needed the bump, and I confirmed each engine reports 29.7.0 or later before I moved on. A couple of nodes sat a minor version back, and I upgraded them before treating the check as done.

Then I looked at how I run docker cp. I pull build logs and artifacts out of my own containers, and I do not point the copy at a container I do not control. The mitigation that matters here is to stop the container before copying, because a stopped container cannot race the walk ¹. I also run the copy without root where the workflow allows it, since the write carries the CLI user’s permissions ¹.

What it changes for me

CopyEscape did not create this class of problem. A convenience command that runs a second program on your machine with your credentials is a trust boundary, whether or not anyone labels one as such. The two habits I now keep are the version check and keeping the copy away from containers I do not fully control. That keeps a routine command from writing outside the destination on a host I own.