CVE-2026-41567: 
cAdvisor Análise e mitigação de vulnerabilidades

CVE-2026-41567 is a container escape vulnerability in Moby (Docker Engine) where the daemon incorrectly resolves decompression binaries from a container's filesystem instead of the host's when handling compressed archive uploads. This allows a malicious container image containing a trojanized decompression binary (e.g., xz or unpigz) to achieve arbitrary code execution with full daemon privileges — including host root UID and unrestricted capabilities — when a user uploads a compressed archive into that container. Affected versions include Docker Engine (Moby) ≤ 28.5.2 / < 29.5.1, and moby/moby v2 < 2.0.0-beta.14. The vulnerability was published on May 18, 2026, and has a CVSS v3.1 base score of 7.2 (High) (GitHub Advisory, Github Advisory DB).

The root cause is an uncontrolled search path element (CWE-427) — specifically, an incorrect ordering of operations in the daemon's archive handling logic. When the PUT /containers/{id}/archive API endpoint receives a compressed archive (xz or gzip), the daemon invokes external decompression binaries such as xz or unpigz, but resolves these binaries from the container's filesystem rather than the host's filesystem. An attacker who controls the container image can replace these binaries with malicious executables. Exploitation requires: (1) a user running a container from a malicious image containing a trojanized decompression binary, and (2) that user uploading a compressed (xz or gzip) archive into the container via cat archive.tar.xz | docker cp - mycontainer:/dir or a direct PUT /containers/{id}/archive API call with compressed content. Standard docker cp usage sending uncompressed tar, and pure-Go decompression formats (bzip2, zstd, and gzip without an unpigz binary in the image), are not affected (GitHub Advisory).

Successful exploitation crosses the container-to-host trust boundary, granting an attacker arbitrary code execution as the Docker daemon process with host root UID and unrestricted Linux capabilities. This effectively constitutes a full container escape, enabling the attacker to read or modify any file on the host, install persistent backdoors, pivot to other containers or host services, and fully compromise the underlying host system. Both confidentiality and integrity of the host are rated High impact, while availability is not directly affected by this vulnerability (Github Advisory DB, GitHub Advisory).

1. Craft a malicious container image: Create a Docker image that includes a trojanized decompression binary — for example, replace /usr/bin/xz or /usr/bin/unpigz with a malicious executable (e.g., a reverse shell script or command that writes an SSH key to the host's /root/.ssh/authorized_keys).
2. Publish or distribute the malicious image: Push the image to a public or private registry, or otherwise make it available to the target user (e.g., via a supply chain compromise or social engineering).
3. Wait for the victim to run the container: The target user pulls and starts a container from the malicious image: docker run -d malicious-image.
4. Trigger the vulnerability: The attacker (or a process acting on their behalf) uploads a compressed archive into the running container using one of the affected methods:
   • cat archive.tar.xz | docker cp - <container_id>:/some/dir
   • curl -X PUT --data-binary @archive.tar.xz http://dockerd/containers/<id>/archive?path=/some/dir
5. Achieve host root code execution: The Docker daemon invokes the trojanized xz or unpigz binary from the container's filesystem with full daemon privileges (host root UID, unrestricted capabilities), executing the attacker's payload on the host (GitHub Advisory).

• Process: Unexpected child processes spawned by the Docker daemon (dockerd) with host root privileges, such as reverse shells, curl, wget, bash, or python processes not associated with normal container workloads.
• File System: Modified or replaced decompression binaries (/usr/bin/xz, /usr/bin/unpigz) within container image layers; unexpected new files in host directories (e.g., new SSH authorized keys in /root/.ssh/, new cron jobs, or new setuid binaries on the host).
• Logs: Docker daemon logs (/var/log/docker.log or journalctl -u docker) showing PUT /containers/{id}/archive requests with compressed content types (application/x-xz, application/gzip) against containers from unfamiliar or untrusted images.
• Network: Unexpected outbound connections from the Docker daemon process to external IPs, particularly shortly after a docker cp or archive upload operation.

The vulnerability is fixed in Docker Engine 29.5.1 and moby/moby v2.0.0-beta.14; upgrading to these versions is the recommended remediation (GitHub Advisory). For environments that cannot immediately upgrade, the following workarounds apply:

• Only run containers from trusted, verified images.
• Use Docker authorization plugins (e.g., OPA, Casbin) to restrict or audit access to the PUT /containers/{id}/archive API endpoint.
• Avoid piping xz- or gzip-compressed archives into containers created from untrusted images; use uncompressed tar archives with docker cp instead (the default CLI behavior is already uncompressed and not affected).

The vulnerability was reported by researcher manizada and remediated by vvoland from the Moby project, with the advisory published on May 18, 2026 (GitHub Advisory). The CISA Vulnerability Bulletin for the week of June 1, 2026 included this CVE, indicating it received attention from U.S. government cybersecurity authorities. No significant broader media coverage or notable social media discussion has been identified beyond standard vulnerability tracking and distribution channels.