Docker Engine: docker cp of a compressed archive runs the container's own xz/unpigz with daemon privileges

Impact

When a compressed archive is uploaded through PUT /containers/{id}/archive or piped in with docker cp -, the daemon resolves the decompression helper (xz, unpigz) from the container's filesystem instead of the host's because of an ordering mistake. A malicious image that ships a trojanized xz or unpigz therefore executes with full daemon privileges: host root UID and unrestricted capabilities. On a GPU node that runs tenant-supplied images, a single routine copy of a .tar.gz into such a container by an operator or a CI job hands over the whole node — every other container on it, the GPU devices, and any node credentials. Exploitation requires that copy to happen, so it is not self-triggering, but the action is a common one.

Who can reach it

Local — the attacker supplies the container image. Execution is triggered when a user or automation with Docker API access uploads a gzip or xz archive into a container created from that image; that copy step is the required user action.

What to do

Upgrade to Docker Engine 29.5.1 or moby/moby v2.0.0-beta.14 and restart dockerd; unless live-restore is enabled the restart cycles running containers on the node. Red Hat has shipped errata for the affected Multicluster Global Hub releases. Interim workarounds from the advisory: run containers only from trusted images, use an authorization plugin to restrict PUT /containers/{id}/archive, and do not pipe compressed archives into containers built from untrusted images.

References