CVE-2026-41568

What it actually does

This vulnerability is a local, low-privilege race condition in Docker/Moby daemon handling of `docker cp` mount setup. When a user or automation invokes `docker cp` against a malicious or compromised container, the container can win a timing race and cause the daemon to create empty files or directories at attacker-chosen absolute paths on the host filesystem. The flaw does not directly disclose data or provide arbitrary file write with attacker-controlled content, but it can affect host filesystem integrity and availability by creating unexpected paths, blocking legitimate file creation, interfering with service behavior, or filling/altering sensitive filesystem locations depending on permissions and path handling by the daemon.

Why it matters to the business

Organizations running affected Docker Engine or Moby daemon versions may be exposed to host-level filesystem tampering from containers, especially where developers, CI/CD jobs, build agents, or operational tooling use `docker cp` with untrusted or tenant-controlled containers. The most likely consequences are service disruption, failed deployments, degraded container host reliability, and operational recovery work caused by unexpected files or directories appearing in critical locations. The CVSS score is moderate and EPSS is currently very low, with no known KEV listing or mature public exploitation reported, but the impact is higher in shared build platforms, developer workstations, container hosting environments, and CI systems that process untrusted containers.

How an attack unfolds

An attacker first obtains the ability to run or influence a container on a host using an affected Docker Engine or Moby daemon. The attacker prepares the container filesystem and behavior to exploit the timing window during `docker cp` mount setup. When an authorized user, script, CI pipeline, or management process runs `docker cp` to copy files to or from that container, the malicious container manipulates filesystem state during the race. If successful, the daemon performs host-side path creation at an arbitrary absolute location selected by the attacker, resulting in an empty file or directory being created on the host. The attacker cannot directly write arbitrary contents through this flaw alone, but may use the created path to disrupt services, pre-create lock files, interfere with later privileged operations, influence software behavior that reacts to path existence, or cause availability issues by creating paths in sensitive locations.

How to fix it

Upgrade Docker Engine to version 29.5.1 or later and upgrade Moby Daemon to version 2.0.0-beta.14 or later where applicable. Docker Daemon versions 28.5.2 and earlier are affected and should be updated. Where immediate upgrade is not possible, reduce exposure by avoiding `docker cp` against untrusted containers, restricting who can access the Docker socket or Docker API, preventing untrusted workloads from running on shared Docker hosts, isolating CI/build containers from production hosts, and using least-privilege operational accounts. Monitor and control automation that performs file copies from containers, and treat access to the Docker daemon as highly privileged because container-to-host boundary weaknesses often become host-impacting issues.

How to confirm the fix worked

Confirm the installed Docker Engine and daemon versions with `docker version` or equivalent package inventory and verify Docker Engine is 29.5.1 or later. For Moby-based deployments, confirm Moby Daemon is 2.0.0-beta.14 or later. Review package manager records, container host images, golden images, CI runner images, and appliance/vendor distributions that bundle Docker or Moby. Validate that `docker cp` usage is limited to trusted containers and that access to `/var/run/docker.sock` or remote Docker API endpoints is restricted. After patching, restart the daemon if required by the package process and confirm the active daemon binary, not just the installed package, reports a fixed version.

Typical attack path

1. Attacker gains the ability to create, run, or supply a malicious container to an environment using an affected Docker Engine or Moby daemon.
2. Attacker crafts container filesystem state and timing behavior to target the `docker cp` mount setup race condition.
3. A legitimate user, automation job, CI/CD pipeline, or operational process invokes `docker cp` against the malicious container.
4. The malicious container changes filesystem state during the race window so the daemon resolves or creates a host path chosen by the attacker.
5. The affected daemon creates an empty file or directory at an arbitrary absolute path on the host filesystem.
6. Attacker leverages the unexpected file or directory for disruption, persistence support, denial of service, or to influence later host-side operations that depend on path existence.

How to detect it

Look for evidence of `docker cp` operations involving untrusted, newly created, or suspicious containers followed by unexpected empty file or directory creation on the host. Relevant sources include Docker daemon logs, systemd journal entries for the Docker service, shell history, CI/CD job logs, auditd file creation events, endpoint detection telemetry, file integrity monitoring alerts, and filesystem metadata changes. Focus on suspicious host path creation events that occur immediately after `docker cp` activity, especially in sensitive locations such as `/etc`, `/root`, `/usr`, `/var/lib`, `/var/run`, `/run`, service configuration directories, cron/systemd locations, application deployment paths, and package manager state directories. Since this vulnerability creates empty files or directories rather than dropping a distinctive payload, detection should rely on behavioral correlation: Docker copy activity plus anomalous zero-byte files, newly created directories, or failed services caused by unexpected path existence. There are no known public threat actors, KEV activity, ransomware association, or mature exploit artifacts reported in the provided intelligence, so no campaign-specific indicators are available.

• docker cp
• /var/run/docker.sock
• dockerd
• containerd
• journalctl -u docker
• POST /containers/
• /archive
• /etc
• /root
• /usr
• /var/lib
• /var/run
• /run
• /etc/cron.d
• /etc/systemd/system
• /usr/local/bin
• /var/lib/docker

What your security team should do

• Inventory all hosts, developer workstations, CI runners, build agents, and container platforms running Docker Engine or Moby Daemon.
• Prioritize upgrades to Docker Engine 29.5.1 or later and Moby Daemon 2.0.0-beta.14 or later on systems that run untrusted containers or use `docker cp` in automation.
• Restrict Docker socket and API access to trusted administrators and tightly controlled service accounts.
• Audit CI/CD jobs, scripts, and operational runbooks for `docker cp` usage against externally supplied or untrusted containers.
• Temporarily disable or gate workflows that copy files to or from untrusted containers until affected daemons are upgraded.
• Harden container hosts by separating untrusted build workloads from production infrastructure and using ephemeral hosts for risky workloads.
• Monitor for unexpected creation of files or directories in sensitive host paths following `docker cp` activity.
• Because EPSS is currently low, not KEV-listed, and exploit maturity is listed as none, treat this as a prioritized hygiene and hardening fix rather than an active mass-exploitation emergency unless local threat exposure is high.