Moby/V2/Daemon

Submit a proposal Propose CVE/GCVE/GHSA reference

Approved changes feed: RSS · Atom

cpe:2.3:a:moby:moby/v2/daemon:*:*:*:*:*:*:*:*

part: a version: * update: *

VendorMoby (8d314c79-7a19-5d13-b09a-3981653aa3ea)
ProductMoby/V2/Daemon (f0199166-48b1-55cf-b913-3e789bb20281)
Edition*
Language*
Software edition*
Target software*
Target hardware*
Other*
NotesImported from gcve-enriched-dumps CVE data

PURL mappings

PURLSourceLast updated
No PURL mappings for this CPE yet.

Vulnerability references

IdentifiercpeApplicabilitySubmitteddb.gcve.eu detailsRationale
CVE:CVE-2026-41567 vulnerable 2026-06-08 08:03:15.560193 Docker: `PUT /containers/{id}/archive` executes container binary on the host
HIGH (7.2)
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
Published: 2026-06-05T00:35:50.563Z
Updated: 2026-08-20T12:31:58.311Z
Reference links
Imported from gcve-enriched-dumps CVE data

Contribute

You can submit an edit proposal for this CPE entry or suggest a related product/vendor addition using the action button above.