CVE-2026-42306

What it actually does

This vulnerability is a race condition in Docker Engine/Moby daemon handling of `docker cp` mount setup. A malicious container can change filesystem state during the copy operation so the daemon follows a redirected bind-mount target to an unintended host path. If successful, the attacker can cause the privileged daemon to overwrite or alter host files, or corrupt critical host paths enough to cause denial of service. Exploitation requires local access to run or control a malicious container and interaction that triggers `docker cp`, and the attack complexity is high because the timing race must be won.

Why it matters to the business

Organizations using vulnerable Docker Engine or Moby versions could face host instability, service outages, or integrity compromise of files on container hosts if untrusted containers are copied from using `docker cp`. The risk is most relevant in shared build systems, CI/CD runners, developer workstations, container hosting platforms, and environments where users can run containers but should not be able to modify host files. This is not currently listed in CISA KEV, has very low EPSS, and has no known public exploit maturity in the provided data, but the impact is significant where container isolation is a security boundary.

How an attack unfolds

An attacker first obtains the ability to create or control a container on a host running a vulnerable Docker Engine or Moby daemon. Inside the container, the attacker prepares filesystem objects such as symlinks, mount points, or rapidly changing paths designed to be swapped during the daemon's `docker cp` path resolution and mount setup sequence. When a privileged user, automation job, or management process runs `docker cp` against the malicious container, the attacker races the daemon's setup logic so that the intended container path is redirected to an arbitrary path on the host. If the race succeeds, the daemon may write to or overwrite host files outside the expected container copy boundary, potentially breaking host services, corrupting configuration, or causing denial of service.

How to fix it

Upgrade Docker Engine to version 29.5.1 or later. Upgrade Moby Daemon to version 2.0.0-beta.14 or later where applicable. If immediate upgrade is not possible, restrict use of `docker cp` against untrusted or user-controlled containers, prevent untrusted users from running containers on shared hosts, avoid automated copy operations from containers that are not built from trusted images, and isolate CI/CD or build workloads so compromise of one container host does not affect production systems. Use least privilege for Docker socket access, because users with Docker API access can typically perform high-impact operations on the host.

How to confirm the fix worked

Confirm the installed Docker Engine version is 29.5.1 or later, or the Moby Daemon version is 2.0.0-beta.14 or later. Validate with `docker version`, package manager inventory, container host configuration management, or daemon build metadata. Confirm older daemon packages have been removed or restarted after upgrade, since patching packages without restarting the daemon may leave the vulnerable process running. Review operational controls to ensure `docker cp` is not used on untrusted containers where upgrade exceptions remain.

Typical attack path

1. Gain low-privileged local access sufficient to run or control a container on a vulnerable Docker Engine or Moby host.
2. Create a malicious container with filesystem paths designed to change during `docker cp` processing.
3. Wait for or induce a user, script, CI job, or platform component to run `docker cp` involving the malicious container.
4. Race the daemon during bind-mount setup by redirecting the copy target to an unintended host path.
5. Use the daemon's privileged file operation to overwrite, corrupt, or otherwise modify host files.
6. Leverage the resulting file integrity impact to disrupt services, damage the host, or potentially set up further compromise depending on what file was modified.

How to detect it

To assess possible prior exploitation, review Docker daemon logs, shell history, CI/CD job logs, endpoint telemetry, and audit logs for `docker cp` operations involving untrusted or short-lived containers on vulnerable hosts. Correlate those events with unexpected file modifications, permission changes, service failures, daemon errors, or host instability immediately afterward. On Linux hosts, inspect auditd or EDR file-write telemetry for privileged `dockerd` writes to sensitive host paths around the time of `docker cp` activity. Review container creation times, image provenance, and container filesystem behavior for suspicious symlink or mount manipulation patterns. Because exploitation is race-based and does not produce a unique network signature, detection is primarily behavioral: suspicious `docker cp` activity followed by anomalous host file changes performed by the Docker daemon process.

What your security team should do

• Prioritize upgrades on shared container hosts, CI/CD runners, build farms, developer jump hosts, and any platform where users can run containers but should not modify host files.
• Upgrade Docker Engine to 29.5.1 or later and Moby Daemon to 2.0.0-beta.14 or later.
• Audit access to the Docker socket, Docker API, and local `docker` group; remove access from users and automation that do not require host-equivalent privileges.
• Temporarily block or tightly control `docker cp` workflows involving untrusted containers until all vulnerable hosts are patched.
• Review recent `docker cp` usage on vulnerable hosts, especially operations involving containers created by untrusted users or CI jobs.
• Ensure daemon restarts are completed after package updates and verify runtime versions, not only installed package versions.