CVE-2026-41567
Received Received - Intake
BaseFortify

Publication date: 2026-06-05

Last updated on: 2026-06-05

Assigner: GitHub, Inc.

Description
Moby is an open source container framework. In versions prior to 29.5.1 and in moby/moby v2 prior to v2.0.0-beta.14, when a compressed archive is uploaded to a container via `PUT /containers/{id}/archive` or piped through `docker cp -`, the daemon resolves decompression binaries (such as `xz` or `unpigz`) from the container's filesystem rather than the host's due to incorrect ordering of operations. A malicious container image containing a trojanized decompression binary can achieve arbitrary code execution with full daemon privileges, including host root UID and unrestricted capabilities, when a user uploads a compressed (xz or gzip) archive into that container. This issue is fixed in Docker Engine 29.5.1 and moby/moby v2.0.0-beta.14. Workarounds include only running containers from trusted images, using authorization plugins to restrict access to the `PUT /containers/{id}/archive` endpoint, and avoiding piping compressed archives into containers created from untrusted images
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-06-05
Last Modified
2026-06-05
Generated
2026-06-05
AI Q&A
2026-06-05
EPSS Evaluated
N/A
NVD
EUVD
Affected Vendors & Products
Showing 3 associated CPEs
Vendor Product Version / Range
moby moby to 29.5.1 (exc)
moby moby to v2.0.0-beta.14 (exc)
docker docker_engine to 29.5.1 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-427 The product uses a fixed or controlled search path to find resources, but one or more locations in that path can be under the control of unintended actors.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

CVE-2026-41567 is a high-severity vulnerability in Docker Engine and Moby container framework versions prior to 29.5.1 and v2.0.0-beta.14 respectively. The issue arises when a user uploads a compressed archive (such as xz or gzip) into a container using the `PUT /containers/{id}/archive` API or via `docker cp` with a compressed stream.

Due to incorrect ordering of operations, the Docker daemon resolves decompression binaries (like `xz` or `unpigz`) from the container's filesystem instead of the host's filesystem. This allows a malicious container image containing a trojanized decompression binary to execute arbitrary code with full daemon privileges, including host root UID and unrestricted capabilities, when the compressed archive is processed.

Exploitation requires running a malicious container image and uploading a compressed archive into it. Standard usage of `docker cp` with uncompressed tar archives is not affected.


How can this vulnerability impact me? :

This vulnerability can lead to arbitrary code execution with full daemon privileges on the host system. An attacker who successfully exploits this issue can gain root-level access to the host, potentially compromising the entire system and all containers running on it.

Such access allows the attacker to perform unrestricted actions, including modifying or deleting data, installing malware, or disrupting services.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

Detection of this vulnerability involves identifying if your Docker Engine or Moby installation is running a vulnerable version prior to 29.5.1 or moby/moby v2 prior to v2.0.0-beta.14.

You can check the Docker Engine version with the command:

  • docker version --format '{{.Server.Version}}'

Additionally, monitor usage of the API endpoint PUT /containers/{id}/archive or the docker cp command when used with compressed archives (xz or gzip).

Look for suspicious container images that might contain trojanized decompression binaries by inspecting container filesystems or image contents.


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation steps include:

  • Upgrade Docker Engine to version 29.5.1 or later, or moby/moby to v2.0.0-beta.14 or later where the issue is fixed.
  • Only run containers from trusted images to avoid malicious trojanized decompression binaries.
  • Use authorization plugins to restrict access to the PUT /containers/{id}/archive API endpoint.
  • Avoid piping compressed (xz or gzip) archives into containers created from untrusted images.

Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart