Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹
🐹 Go
Not in CISA KEV
MEDIUM severity

CVE-2026-41568 — docker

MEDIUM

CVE-2026-41568 is a medium-severity (CVSS 6.1) CWE-81 vulnerability in github.com/docker/docker. A fix is available for github.com/docker/docker — see the affected versions and patch details below.

Moby: Race condition in docker cp allows creation of arbitrary empty files on the host via symlink swap

Also known asGHSA-vp62-88p7-qqf5GO-2026-5668
Published
Jun 12, 2026
Updated
Sep 9, 2026
Affected
3 pkgs
Patched
1 / 3
Exploits
None indexed
Exploitation data as of Sep 30, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

  • CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-41568.

EPSS Exploitation Probability

via FIRST.org ↗
0.1%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs1th percentile — riskier than 1% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

CVE-2026-41568 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 380,526 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

3 pkgs affected
🐹github.com/docker/docker🐹github.com/moby/moby/v2🐹github.com/moby/moby

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

Summary

A race condition during docker cp mount setup allows a malicious container to create empty files or directories at arbitrary absolute paths on the host filesystem.

This advisory covers the race during mountpoint creation. The related race during the subsequent mount syscall is tracked in GHSA-rg2x-37c3-w2rh

Details

When copying files into a container, the daemon sets up a temporary filesystem view by bind-mounting volumes into a private mount namespace. During this setup, the mount destination path is first resolved within the container's root filesystem using GetResourcePath, and then used to create the mountpoint (file or directory) if it does not already exist via createIfNotExists.

Between path resolution and mountpoint creation, a process running inside the container can swap a path component for a symlink pointing to an arbitrary location on the host. Because createIfNotExists operates on the already-resolved absolute path using standard os.MkdirAll and os.OpenFile — which follow symlinks in intermediate path components — the symlink is followed and the file or directory is created outside the container root filesystem, as root.

Impact

A malicious container can create empty files or directories at arbitrary absolute paths on the host filesystem, running as root. This enables persistent denial of service — for example:

  • Converting /etc/docker/daemon.json into a directory prevents the daemon from restarting
  • Creating /etc/nologin prevents user logins
  • Overwriting critical system paths with empty files can break host services

The container does not gain read or write access to existing host files — only the ability to create new empty files or directories at chosen paths.

Conditions for exploitation

  • A container must be running with a process that can rapidly create and swap symlinks at a volume mount destination path.
  • An operator must initiate a docker cp into that container, or call the PUT /containers/{id}/archive or HEAD /containers/{id}/archive API endpoints.

Not affected

  • Containers that do not have volume mounts are not affected, as the race occurs during volume bind-mount setup.

Patches

Mountpoint creation is now scoped to the container root using os.Root (Go 1.24+), which refuses to follow symlinks that escape the opened root directory. All filesystem operations in createIfNotExists (MkdirAll, OpenFile) are performed through the os.Root handle, so even if a symlink swap occurs after path resolution, the creation stays confined to the container root.

Workarounds

  • Only run containers from trusted images.
  • Avoid using docker cp with untrusted running containers.
  • Use authorization plugins to restrict access to the archive API endpoints (PUT /containers/{id}/archive, HEAD /containers/{id}/archive).

Affected Packages

3 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/docker/dockerall versionsNo fix
🐹Gogithub.com/moby/moby/v2all versions2.0.0-beta.14go get github.com/moby/moby/v2@v2.0.0-beta.14
🐹Gogithub.com/moby/mobyall versionsNo fix

Affected Products

3 products · 16 configurations
Application
enginedocker
< 29.5.1
range
Application
mobymobyproject
≤ 28.5.2
range
Application
moby\/v2mobyproject
1 version
2.0.0

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/docker/docker, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    No patched version of github.com/docker/docker has shipped for CVE-2026-41568 yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.

  3. Workarounds

    Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.

Fixing This On Your OS

If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.

Red HatLow

This flaw is rated as Low impact. A race condition in the `docker cp` mount setup within the Moby container framework allows a malicious container to create empty files or directories at arbitrary locations on the host filesystem. Successful exploitation is difficult (AC:H) due to the timing-dependent nature of the…

Workaround published by Red Hat
Avoid using docker cp with untrusted running containers. Recommended to apply patches: Mountpoint creation is now scoped to the container root using os.Root (Go 1.24+), which refuses to follow symlinks that escape the opened root directory. All filesystem operations in createIfNotExists (MkdirAll, OpenFile) are performed through the os.Root handle, so even if a symlink swap occurs after path resolution, the creation stays confined to the container root.
Source: Red Hat security advisory for CVE-2026-41568 (CC BY 4.0)
ProductFixed inAdvisory
Red Hat Openshift Data Foundation 4.22odf4/cephcsi-rhel9:1782932114RHSA-2026:37387

Frequently Asked Questions

## Summary A race condition during `docker cp` mount setup allows a malicious container to create empty files or directories at arbitrary absolute paths on the host filesystem. This advisory covers the race during mountpoint creation. The related race during the subsequent mount syscall is tracked in GHSA-rg2x-37c3-w2rh ## Details When copying files into a container, the daemon sets up a temporary filesystem view by bind-mounting volumes into a private mount namespace. During this setup, the mount destination path is first resolved within the container's root filesystem using `GetResourceP
O3 Security · Impact-Aware SCA

Is CVE-2026-41568 in your dependencies?

Find it across Go, including transitive dependencies.