Docker CopyEscape (CVE-2026-17106): Fix the docker cp Host File Overwrite Vulnerability

If you or your CI pipeline ever run docker cp against a container you didn't fully trust — a scanning sidecar, a customer-submitted build, an AI-agent sandbox — you need to check your Docker version right now. CVE-2026-17106, nicknamed CopyEscape by the Imperva Threat Research team that found it, lets a malicious or compromised container write files anywhere on the host that the user running docker cp can write to. On Linux, where copy operations are frequently run as root, that's a path to full host takeover.

What CopyEscape actually is

docker cp looks like a simple, one-directional operation: pull files out of a container and drop them on the host. Docker's extraction code assumes the tar stream it's reading matches the container filesystem it inspected a moment earlier. CopyEscape breaks that assumption with two chained flaws in moby/go-archive, the library Docker Engine and CLI use to build and extract these archives:

• A TOCTOU (time-of-check-to-time-of-use) race. While the Docker daemon walks a container's filesystem to build the tar archive, a process running inside that container can rename files and swap in symlinks in real time. The daemon ends up packing a tar stream that no longer matches what it originally inspected.
• A path-validation mismatch on extraction. The Docker CLI validates one constructed destination path, but actually writes using a second path derived from the archive's (attacker-controlled) symlink data. A crafted archive can point that second path outside the destination directory entirely — at ~/.ssh/authorized_keys, a shell profile, or on Linux, a system binary like /usr/bin/runc if the copy runs with elevated privileges.

Put together: a container you're copying from can decide what gets written on your host, not just what you asked to copy out. Researchers demonstrated both a macOS PoC (dropping a file in the user's home directory) and a Linux PoC (overwriting a system binary), and a public proof-of-concept repository is already available, so this isn't a theoretical race condition — it's a demonstrated, reproducible one.

The flaw also extends beyond plain docker cp: the related sbx cp command used by Docker Sandboxes — Docker's isolated execution environments built for running untrusted or AI-agent-generated code — uses the same underlying extraction path and is affected too, which is a sharper problem given that Sandboxes exist specifically to run code you don't trust.

Are you affected?

You're exposed if any of the following are true:

• You run docker cp (in either direction) against containers built from images you don't fully control — third-party base images, customer-submitted Dockerfiles, CI jobs that build and then inspect untrusted code.
• You use docker cp in automation that runs as root or with sudo, including CI runners, build agents, or ops scripts.
• You use Docker Sandboxes (sbx cp) for AI-agent or untrusted-code workflows.
• You haven't explicitly upgraded Docker Engine, CLI, or Desktop since late July/early August 2026.

Check your current version first:

1docker version --format '{{.Server.Version}}'
2docker version --format '{{.Client.Version}}'

The fix

Docker has already shipped patches — this is a straightforward upgrade, not a config workaround:

The underlying fix landed in github.com/moby/go-archive v0.3.0, tracked as GHSA-hfg8-hc9c-6c3h (CVSS 7.1, High), and Docker Engine 29.7.0 pulled that dependency update in directly.

On Linux servers (Engine + CLI):

1# Debian/Ubuntu (apt)
2sudo apt-get update
3sudo apt-get install --only-upgrade docker-ce docker-ce-cli
4
5# RHEL/Amazon Linux (dnf/yum)
6sudo dnf update docker-ce docker-ce-cli
7
8# Confirm the fix landed
9docker version --format '{{.Server.Version}}'   # expect 29.7.0+

On Docker Desktop (Mac/Windows): open Docker Desktop → check for updates, or download the latest installer directly from docker.com. Confirm via Docker Desktop → About Docker Desktop that you're on 4.86.0 or later.

If you're pinned to an older Engine major version for compatibility reasons and can't jump to 29.7.0 immediately, treat the mitigations below as mandatory until you can.

Mitigations if you can't upgrade immediately

Docker's own guidance, if a patched version isn't yet an option in your environment:

• Don't run docker cp against running, untrusted, or potentially compromised containers. Stop the container first if you need to pull files out of it — a stopped container's filesystem can't race the archive builder.
• Never run docker cp as root, or via sudo, as a matter of course. Use the minimum privilege the operation actually needs. This is the single biggest severity multiplier — the flaw only reaches root-level host compromise when the copy itself runs with elevated privileges.
• Isolate copy operations involving untrusted images in a disposable VM or throwaway account rather than your primary workstation or a shared build host.
• Audit CI/CD pipelines specifically. docker cp shows up quietly in test-artifact extraction steps, log collection, and coverage-report pulls — exactly the kind of automation that runs unattended, as a privileged service account, against containers built from arbitrary (including PR-submitted) code.

Common mistakes to avoid

• Assuming this only matters for public-facing systems. The attack requires you to run docker cp against a container that's already compromised or adversarial — which includes your own CI running someone else's pull request, not just internet-facing infrastructure.
• Patching Desktop but not your CI runners. Desktop and Engine/CLI ship and version independently; a fixed laptop doesn't mean your build fleet is fixed.
• Trusting docker --version output loosely instead of checking Server.Version explicitly — client and daemon can be on different versions, especially with remote Docker contexts.
• Forgetting Docker Sandboxes as a separate surface. If your team adopted Sandboxes for AI-agent code execution, that's a second component (sbx cp) that needs its own version check, not something covered automatically by patching Engine/CLI.

Troubleshooting

apt-get install --only-upgrade says the package is already at the latest version, but it's older than 29.7.0. Your apt sources are likely pointing at a stale or pinned Docker repository. Re-add the official repo per Docker's install docs and re-run apt-get update before upgrading.

Docker Desktop shows "up to date" but the version is below 4.86.0. Desktop's auto-update channel can lag; download the installer directly from docker.com and reinstall over the existing installation rather than waiting for the in-app updater.

You need to confirm the fix without a version check (e.g., a locked-down environment where you can't easily trust version strings). Test with the public PoC repository referenced in Imperva's writeup in an isolated, disposable VM — a patched daemon should reject the malicious archive or complete the copy without writing outside the selected destination.

FAQ

Do I need to rebuild my container images to fix this? No. This is a Docker Engine/CLI/Desktop vulnerability, not an image vulnerability — patching the Docker installation itself is what fixes it. Your existing images don't need to change.

Is docker cp unsafe to use at all until I patch? It's unsafe specifically against untrusted or potentially compromised containers, and riskier still when run as root. Copying from containers you built yourself, from trusted images, in a non-privileged context, is low risk even pre-patch — but there's no reason not to just upgrade.

Does this affect Kubernetes' kubectl cp? kubectl cp has a related but historically separate history of tar-extraction path-traversal issues and isn't automatically fixed by a Docker Engine upgrade — don't assume patching Docker covers your Kubernetes clusters. Check your kubelet/container runtime version separately if you rely on kubectl cp for similar workflows.

What's the CVSS score and why does it matter? 7.1 (High), under CVSS 4.0. It's not the maximum-severity 9-10 range because exploitation requires an attacker to already control code running inside a container you then choose to docker cp from — but "High" for an unauthenticated container-to-host escape is still an upgrade-now issue, not a queue-it-for-next-sprint one.

Is there a CVE for Docker Sandboxes specifically? Docker Sandboxes' sbx cp shares the same underlying moby/go-archive extraction code and CVE-2026-17106 covers it too — the fix is the Sandboxes 0.38.0+ release rather than a separate advisory. Verify your Sandboxes version the same way you'd verify Engine/CLI.

Key takeaways

Further Reading

• Docker VMM Public Beta: What Docker's First-Party Virtualization Engine Changes — also shipped in Docker Desktop 4.86, the same release that carries this fix.
• Docker Hub OIDC for GitHub Actions: Retire Your Stored Access Tokens — another recent Docker security-hardening change worth auditing your pipelines against.
• Terraform MCP Server CVSS 10.0 Vulnerabilities: Patch Now — a similar recent supply-chain-adjacent CVE if you're building out a patch-tracking habit.
• Official advisory: GHSA-hfg8-hc9c-6c3h — moby/go-archive
• Official write-up: CopyEscape: Taking Over Docker Hosts with docker cp — Imperva