By docker cp is one of those commands developers run on autopilot — copy test results out of a build container, grab a log file, pull a compiled artifact. Nobody thinks twice about it. Imperva’s Red Team just gave you a reason to. CopyEscape (CVE-2026-17106) turns your own docker cp command into a write primitive that a malicious container can aim at any file on your host. On Linux with elevated privileges, it hands over root. The patch exists. Use it.
What CopyEscape Actually Does
The vulnerability lives in moby/go-archive, Docker’s shared archive library. It chains two weaknesses that individually look minor but combine into something genuinely dangerous.
The first is a TOCTOU race. Docker locks its internal state while walking a container’s filesystem to build a tar stream — but it does not lock the container’s filesystem itself. A malicious container process uses inotify and timed directory swaps to manipulate files while Docker’s walker is mid-scan: Docker records a directory, the container swaps it for a symlink pointing outside the intended destination, and that symlink ends up baked into the archive.
The second is a path validation bypass in Docker’s extraction code. The validator checks one constructed path, but the actual symlink is created from a different, unchecked path in the archive. The planted symlink survives extraction and lands outside the target directory on the host — wherever the attacker aimed it. The full technical breakdown is in Imperva’s writeup.
Who Is Exposed
Anyone who runs docker cp against a live or untrusted container — which is a wide net.
CI/CD pipelines are the highest-risk target. Most build workflows copy artifacts, test results, or coverage reports out of containers as a standard step. GitHub Actions runner images across Ubuntu 22.04, 24.04, and 26.04, macOS 14, 15, and 26, and Windows Server variants were all shipping vulnerable Docker versions, tracked in Actions runner issue #14554. Any pipeline pulling from an external base image is potentially in scope.
Developer workstations running docker cp against debug containers are exposed too. So is AI-agent tooling: Docker Sandboxes uses sbx cp, which shares the same vulnerable archive pipeline. If your coding agent is pulling files out of a sandboxed environment that processed untrusted code or external packages, that is the same attack surface.
The Root Execution Path
On macOS, the worst case is overwriting shell config files, executables in your home directory, SSH keys, or source code — serious, but bounded to your user context. On Linux when docker cp runs with elevated privileges — common in automation scripts, CI jobs, and incident-response workflows — the blast radius expands. The write primitive can replace /usr/bin/runc, the container runtime binary. The next time anything starts a container, it executes attacker-controlled code as root. The proof-of-concept is public on GitHub.
Patch Now
Docker shipped the fix. The patched versions are:
- Docker Engine and CLI: 29.7.2
- Docker Desktop: 4.86.0
- Docker Sandboxes: 0.38.0
# Check your current version
docker version --format '{{.Server.Version}}'
# Must show 29.7.2 or higher
# Linux (apt)
sudo apt-get update && sudo apt-get install --only-upgrade docker-ce
# macOS / Windows
# Docker Desktop: Settings > Check for Updates
# Or via Homebrew:
brew upgrade --cask dockerIf You Cannot Patch Immediately
Three mitigations that eliminate or reduce the risk while you plan the upgrade:
- Stop containers before copying. The TOCTOU race requires the container to be running.
docker stop <container>beforedocker cpcloses the attack window entirely. - Never use
sudo docker cpagainst untrusted containers. Elevated privileges are what enable the runc overwrite path. - Prefer volume mounts over runtime
docker cp. For CI artifact collection, bind-mount an output directory at container start instead of usingdocker cpafter the run.
A Pattern Worth Noting
This is not the first time docker cp‘s archive code has been the problem. CVE-2019-14271 was the previous most-severe copy vulnerability. CVE-2026-31431 (“Copy-Fail”), disclosed separately this year, is another container escape through the same general mechanism. The archive pipeline has been an under-audited attack surface for years. The lesson from CopyEscape is not just to patch this CVE — it is to treat any file transfer out of a running container as a potentially hostile operation until proven otherwise. Stop the container first. Always.
