Docker/Daemon

Submit a proposal Propose CVE/GCVE/GHSA reference

Approved changes feed: RSS · Atom

cpe:2.3:a:docker:docker/daemon:*:*:*:*:*:*:*:*

part: a version: * update: *

VendorDocker (fb312c2d-be4d-5919-b619-61409dcafa2c)
ProductDocker/Daemon (e27e4ed0-862b-519d-8943-16aa9a438be7)
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.568201 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-07-30T12:04:58.332Z
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.