One of the most routine commands in a developer's day, docker cp, can be turned against the machine running it. A flaw the Imperva Red Team named CopyEscape, tracked as CVE-2026-17106, lets a malicious container write files to arbitrary locations on the host and, in the right conditions, get its code executed there. Docker has released fixes.
The details reached us through a national security alert published by Peru's CNSD, the country's national digital security centre, which summarises the Imperva Red Team's own writeup. Imperva's blog post carries the full technical detail; the bulletin does not reproduce a CVSS score, and none was published alongside it.
What is affected
The problem sits in docker cp, the command that copies files in and out of a container, and in the equivalent sbx cp command used by Docker Sandboxes. According to the bulletin, Docker validates one version of the destination path but then creates the symbolic link using a different path that was never properly checked. That mismatch is what lets a container break out of its own filesystem and land files somewhere else on the host.
What makes it awkward is where docker cp is normally used. Developer laptops, CI/CD pipelines and incident response all lean on it to pull build artefacts, logs and evidence out of containers. Simply retrieving data from a container you already suspect is compromised can be enough to trigger the exploit. The sbx cp variant extends the same risk into Docker Sandboxes, which AI coding agents use to run untrusted code, so an agent tidying up after a sandbox run is doing exactly the thing that sets this off.
The impact differs by platform. On macOS, Docker Desktop runs the daemon inside a virtual machine, but the client still performs the file extraction locally, so an attacker can aim at shell startup files, SSH configuration or LaunchAgents and wait for the developer to open a new terminal. On Linux the ceiling is higher: where docker cp runs with elevated privileges, which is common in automation, an attacker can replace critical system files such as runc and convert a file write into root access.
What you should do
Docker fixed the flaw in Docker Engine and CLI 29.7.2, Docker Desktop 4.86.0, and Docker Sandboxes 0.38.0. The bulletin notes the fix followed a disclosure process that began in April 2026 and needed several extensions to deal with regressions in an earlier attempt, so partial patches are not enough here. Update to those versions or later.
Until you have, CNSD's guidance is to avoid running docker cp against untrusted, compromised or still-running containers, and to stop the container before copying anything out of it. Avoid sudo docker cp unless it is genuinely required, run the Docker CLI with least privilege, and audit any automation or CI/CD job that calls docker cp with elevated rights.
Container isolation failures keep proving that the boundary is thinner than teams assume, whether the break comes from an old kernel bug repurposed into a container escape or from storage drivers that let one tenant read another's files. A command that reads files out of a container deserves the same scepticism as one that runs code inside it.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.