Docker Fixes CVE-2026-17106: CopyEscape Flaw Can Write Files to the Host

CVE-2026-17106, a newly disclosed Docker vulnerability dubbed CopyEscape, can allow a malicious container to create or overwrite files on the host system when a user copies files from the container.

Docker has released security updates addressing the vulnerability, which affects the widely used docker cp functionality as well as the sbx cp command used by Docker Sandboxes.

The vulnerability is particularly important for developers, server administrators, CI/CD environments, and organizations that run containers obtained from potentially untrusted sources.

Under certain conditions, exploitation can go beyond modifying host files and lead to code execution with the privileges of the user running the Docker command.

Docker addressed CVE-2026-17106 in updated versions of its products and is advising affected users to upgrade.

What Is CVE-2026-17106?

CVE-2026-17106 is a container-to-host arbitrary file-write vulnerability discovered by researchers from the Imperva Red Team.

The vulnerability targets an operation that appears routine:

docker cp container:/path/file ./destination

Administrators and developers commonly use docker cp to move files between running containers and the host.

For example, an administrator might use it to retrieve application logs, configuration files, database exports, debugging information, or generated artifacts.

Normally, files copied from the container should be written only to the destination selected by the user.

CopyEscape breaks that security assumption.

According to the researchers, a malicious container can manipulate the copy operation so that files are written outside the intended destination on the host.

That turns a simple file-copy command into a potential container-to-host attack path. Imperva

Why CopyEscape Is Dangerous

Containers are generally expected to provide a security boundary between workloads and the host operating system.

CVE-2026-17106 is significant because the attack crosses that boundary during a file-copy operation.

A malicious container may potentially cause Docker to create or overwrite files that the user performing the copy has permission to modify.

Possible targets could include:

• shell configuration files;
• application files;
• scripts;
• executables;
• SSH configuration;
• source code;
• startup or persistence mechanisms.

The ultimate impact therefore depends heavily on which user executes docker cp.

If Docker commands are being executed by an ordinary user, the attacker may gain the ability to execute code with that user’s privileges.

The consequences become substantially more serious when Docker commands are executed as root or through sudo.

Imperva demonstrated that Linux environments can potentially be attacked by targeting components such as the runc executable, creating a path toward root-level code execution under the appropriate conditions. Imperva

How the CVE-2026-17106 Attack Works

The underlying vulnerability is more complex than a traditional directory traversal bug.

Imperva’s analysis describes an attack chain involving Docker’s archive handling during the copy process.

When a user copies data from a container, Docker must inspect the container filesystem, create an archive representation of the requested files, transfer that data, and extract it at the destination.

The researchers discovered that a malicious container could manipulate filesystem objects while this process was taking place.

This creates a race condition between Docker checking a filesystem object and subsequently using it.

The attack also involves unsafe handling of symbolic links during archive extraction.

Together, these behaviors can result in an archive that causes the Docker client to write data somewhere other than the location originally selected by the user.

In security terminology, the problem includes a time-of-check/time-of-use (TOCTOU) race condition combined with inadequate path containment during extraction. Imperva

The important point for administrators is simpler:

The container does not need normal write access to the host filesystem for the attack to work.

Instead, the attacker abuses the trusted Docker copy operation being performed by the host user.

Exploitation Requires a Malicious Container

CVE-2026-17106 should not be interpreted as allowing any remote attacker on the Internet to immediately compromise every Docker server.

An attacker first needs control over content inside a container involved in the vulnerable copy operation.

A user must then perform an affected operation such as copying data out of that malicious container.

This makes the vulnerability especially relevant in environments where containers or workloads are not completely trusted.

Examples include:

• CI/CD pipelines;
• developer workstations;
• shared development infrastructure;
• automated build environments;
• systems processing third-party container images;
• security testing environments;
• AI coding and development sandboxes.

A compromised application running inside an otherwise legitimate container could potentially create a similar situation if an administrator later copies attacker-controlled files from that container.

Docker Sandboxes Are Also Affected

The issue is not limited to the traditional Docker Engine workflow.

Docker confirmed that CVE-2026-17106 also affected the sbx cp copy-out operation used by Docker Sandboxes.

Docker Sandboxes are designed to provide isolated environments for workloads including AI agents and development tools.

That makes this aspect of the vulnerability particularly interesting in 2026 as AI coding agents increasingly execute commands and manipulate files inside isolated environments.

Docker’s release notes state that the destination-escape flaw in sbx cp has been fixed in the updated Sandboxes release. Docker Documentation

Public Proof-of-Concept Details Are Available

The vulnerability should receive prompt attention because technical details have already been publicly disclosed.

NHS England’s cyber security advisory notes that public technical analysis and proof-of-concept information describing exploitation through malicious containers and the affected copy commands is available. NHS England Digital

This changes the risk profile compared with a vulnerability for which exploitation techniques remain private.

Once detailed research is public, reproducing the technique generally becomes easier for security researchers — and potentially attackers.

At the time of writing, however, the presence of public proof-of-concept material should not be confused with confirmed widespread exploitation in the wild.

Which Docker Versions Are Affected?

Docker has released updates for the affected components.

Docker’s own security announcements confirm that Docker Desktop 4.86.0, released on August 10, addresses CVE-2026-17106. Docker Documentation

Docker Engine release notes also document a security update to the underlying go-archive component to resolve CVE-2026-17106. Docker Documentation

NHS England’s advisory identifies affected installations across Docker Engine, Docker Desktop, Docker Sandboxes, and Docker CLI components and recommends upgrading affected systems to current supported releases. NHS England Digital

Because Docker components may be packaged differently by Linux distributions and infrastructure vendors, administrators should check both their installed Docker version and their operating system’s security repositories.

How to Check Your Docker Version

Server administrators can check the installed Docker version with:

docker version

For a shorter output:

docker --version

A typical result looks similar to:

Docker version 29.x.x, build xxxxxxx

Docker Desktop users can check their installed release from the application’s settings or About screen.

Docker Sandbox users should also verify the installed Sandbox version rather than assuming that updating Docker Desktop automatically resolves every component in every deployment scenario.

Server Administrators Should Update Docker

Organizations running affected Docker components should prioritize updating them.

On Ubuntu or Debian installations using Docker’s official repository, the process will typically involve refreshing package metadata and installing available Docker updates:

sudo apt update
sudo apt upgrade

Administrators can inspect installed Docker packages with:

dpkg -l | grep docker

On RPM-based systems:

rpm -qa | grep -i docker

Exact package names and patched versions can differ depending on whether Docker came from Docker’s official repository, the Linux distribution repository, Docker Desktop, or another software distribution mechanism.

For that reason, administrators should verify their installed packages against the vendor’s security information rather than relying solely on a generic version command.

Docker security announcements

Do Not Trust Unknown Containers

CVE-2026-17106 is also a reminder that containers should not automatically be considered trusted simply because they execute inside an isolated environment.

Organizations should be cautious when running images from:

• unknown Docker Hub publishers;
• public registries;
• unverified GitHub projects;
• third-party build systems;
• customer-controlled workloads;
• development environments that execute arbitrary code.

Container isolation reduces risk, but it does not eliminate vulnerabilities in the software responsible for managing the container boundary.

In this case, the dangerous operation occurs when trusted host-side Docker software processes data controlled by the container.

CI/CD Systems May Face Higher Risk

CI/CD infrastructure deserves particular attention.

Modern pipelines frequently create temporary containers, execute third-party code inside them, and retrieve build artifacts afterward.

A simplified workflow could look like:

Download source
      ↓
Create container
      ↓
Build application
      ↓
Copy artifact from container
      ↓
Publish artifact

The fourth step can involve functionality similar to the affected Docker copy mechanism.

If an attacker controls the repository, dependency, build process, or container contents, a seemingly harmless artifact extraction operation could become part of an attack chain.

Organizations running automated container workloads should therefore review where docker cp is used in scripts and pipelines.

A quick Linux search can help identify explicit usage:

grep -R "docker cp" /opt /srv /etc 2>/dev/null

CI configuration repositories should be searched separately.

Running Docker as Root Increases the Potential Impact

Linux administrators should pay particular attention to scripts containing commands such as:

sudo docker cp ...

If exploitation succeeds, the ability to write files is related to the privileges of the process performing the copy.

Running the operation with elevated privileges therefore increases the possible damage.

This does not mean running Docker without sudo automatically makes a system safe.

Membership in the traditional docker group itself provides extremely powerful access on many Linux configurations and is commonly treated as effectively root-equivalent.

The vulnerability nevertheless reinforces a fundamental security principle:

automation should run with the minimum privileges necessary to perform its job.

Docker Desktop Users Should Upgrade to 4.86.0 or Later

For Docker Desktop users, the remediation path is particularly straightforward.

Docker states that CVE-2026-17106 was addressed in Docker Desktop 4.86.0. Docker Documentation

Users running older versions should update Docker Desktop rather than assuming the application’s virtualization layer prevents exploitation.

The vulnerability affects the interaction between container-controlled data and host-side Docker functionality, making the host operating system relevant to the final impact.

Docker Desktop installations on Windows, macOS, and Linux therefore deserve review.

What Sysadmins Should Do Now

For most administrators, responding to CVE-2026-17106 does not require redesigning the entire container infrastructure.

The immediate response is relatively clear:

1. Check the Docker versions deployed across servers and workstations.
2. Install current vendor-provided security updates.
3. Update Docker Desktop to 4.86.0 or newer.
4. Update Docker Engine/CLI using the appropriate vendor or distribution packages.
5. Update Docker Sandboxes where they are deployed.
6. Search automation and CI/CD pipelines for docker cp and sbx cp.
7. Avoid copying files from untrusted containers until affected systems are patched.
8. Review workflows that execute Docker commands with elevated privileges.

Organizations managing large Docker fleets should also ensure that developer laptops are included.

Developer workstations can be particularly attractive targets because they often contain SSH keys, cloud credentials, source code, API tokens, and access to production infrastructure.

Why CVE-2026-17106 Matters

CopyEscape demonstrates an important limitation of container security assumptions.

The vulnerability does not primarily attack an application listening on a network port.

Instead, it abuses a trusted administrative action.

An administrator believes they are performing something simple:

docker cp container:/logs/app.log ./

But if the container is malicious, the operation can potentially affect files elsewhere on the host.

That makes CVE-2026-17106 particularly relevant to environments where administrators routinely interact with containers they did not build themselves.

It also illustrates why container security cannot stop at protecting the Docker socket.

Container runtimes, archive extraction, image handling, build systems, management APIs, and host-side CLI tools all form part of the attack surface.

The Bottom Line

Docker has patched CVE-2026-17106, also known as CopyEscape, after researchers discovered that malicious containers could abuse Docker’s file-copy functionality to write outside the intended destination on the host.

The vulnerability affects docker cp and was also confirmed in Docker Sandboxes’ sbx cp functionality.

Successful exploitation can allow arbitrary file creation or overwrite with the privileges of the user running the Docker command. Under certain Linux configurations and privilege levels, the attack can potentially lead to root-level code execution. NHS England Digital

The good news is that fixes are available.

Server administrators, developers, and organizations using Docker in automated build environments should update affected Docker components and pay particular attention to systems that copy files from untrusted containers.