Brief Summary: CVE-2026-41567 in Docker/Moby — Container Escape via Decompression Binary Path Hijacking

Introduction

A container escape vulnerability in Docker Engine's archive-handling logic lets a malicious container image execute arbitrary code with full host root privileges. The attacker only needs to trick a user into uploading a compressed archive into the container. CVE-2026-41567 resolves decompression binaries from the container's filesystem rather than the host's. That breaks the container-to-host trust boundary and turns a routine docker cp operation into a route to host root.

The Docker container market was valued at approximately USD 6.12 billion in 2025, and Docker Engine runs in virtually every enterprise development and production environment, so the blast radius of this vulnerability is substantial. The flaw affects all Docker Engine versions prior to 29.5.1 and the moby/moby/v2 Go module prior to v2.0.0-beta.14.

Technical Information

Root Cause: Uncontrolled Search Path Element (CWE-427)

CVE-2026-41567 is classified under CWE-427 (Uncontrolled Search Path Element), defined by MITRE as a condition where "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."

The vulnerability is in how the Docker daemon handles compressed archive uploads. When a user uploads a compressed archive to a container via the PUT /containers/{id}/archive API endpoint, or pipes compressed data through docker cp -, the daemon must decompress the archive before extracting its contents. To do this, it invokes external decompression utilities: xz for xz-compressed archives and unpigz for gzip-compressed archives.

The flaw is an incorrect ordering of operations in the daemon's archive-handling logic. The code resolves these decompression binaries from the container's filesystem PATH instead of from the host filesystem, where the daemon runs. The container therefore controls which binary the daemon executes.

The Docker daemon process runs as host root with unrestricted Linux capabilities, so any binary it executes inherits those full privileges. A trojanized xz or unpigz binary placed inside a malicious container image at a standard PATH location (such as /usr/bin/xz) will execute with complete host root access when the vulnerable code path is triggered.

Scope and Boundary Crossing

The CVSS v3.1 score of 7.2 (High) includes a Scope:Changed metric, which signals that this vulnerability crosses a trust boundary. The vulnerable component is the Docker daemon's archive handler, but the impact extends to the host system. The full CVSS breakdown:

Attack Flow

The exploitation chain has five steps:

1. Image Preparation: An attacker creates a malicious container image that includes a trojanized xz or unpigz binary at a location on the container's PATH (for example, /usr/bin/xz). This binary contains the attacker's payload.

2. Container Deployment: The victim runs a container from this image. This could happen unknowingly if the image is distributed via a public registry, or if a supply chain compromise introduces the trojanized binary into an otherwise legitimate image.

3. Trigger Condition: The victim uploads a compressed archive into the running container. This can happen in two ways:

   • The Docker Engine API: PUT /containers/{id}/archive with an xz or gzip-compressed payload
   • The CLI: piping compressed data through docker cp - into the container

4. Binary Resolution Error: The Docker daemon looks up the decompression binary it needs. Because of the incorrect operation ordering, it resolves the binary from the container's filesystem rather than the host's.

5. Host Root Execution: The trojanized binary executes with the daemon's full host root UID and unrestricted capabilities. The attacker now has arbitrary code execution on the host system.

What Is Not Affected

Not every docker cp operation or compression format is vulnerable. The advisory explicitly lists the following as not affected:

• Standard docker cp with uncompressed tar archives
• bzip2-compressed archives (uses a pure Go implementation)
• zstd-compressed archives (uses a pure Go implementation)
• gzip-compressed archives when no unpigz binary exists in the container (falls back to Go's native gzip implementation)

Only xz-compressed archives, and gzip-compressed archives handled by unpigz, trigger the vulnerable code path when piped into containers. The reason is that only xz and unpigz decompression shells out to an external binary. The other formats use pure Go implementations that never invoke external processes.

Patch Information

The Moby/Docker project fixed CVE-2026-41567 in Docker Engine v29.5.1, released on May 18, 2026. @vvoland (Pawel Gronowski) developed the fix, which was published under GitHub Security Advisory GHSA-x86f-5xw2-fm2r. @manizada reported the vulnerability.

The patch corrects the ordering of operations so that the daemon resolves decompression binaries exclusively from the host filesystem before it consults any container filesystem path. This removes the container-to-host trust boundary violation entirely.

Affected and Patched Versions

Docker Engine users can resolve the issue by upgrading to v29.5.1 or later. v29.5.1 was a dedicated security release, and it also bundled fixes for two related docker cp TOCTOU vulnerabilities (CVE-2026-41568 and CVE-2026-42306).

A follow-up release, v29.5.2 (May 20, 2026), fixed a regression introduced by the v29.5.1 security fixes. With that regression, docker cp could fail with a "mkdirat: file exists" error when a container had bind mounts traversing in-container symlinks. Docker Engine 29.5.3, released June 3, 2026, is the latest stable release and includes additional fixes.

Migration Note for Downstream Consumers

No backported patch exists on the legacy github.com/docker/docker or github.com/moby/moby Go module paths (versions ≤ 28.5.2). Downstream consumers relying on those paths must migrate their dependencies to the github.com/moby/moby/v2 module (v2.0.0-beta.14+), or make sure their upstream dependencies pull from the patched Moby codebase.

Workarounds

For environments where immediate patching is not feasible, the advisory documents three workarounds:

1. Only run containers from trusted images: Pull images only from verified registries, and use image signing and verification (e.g., Docker Content Trust, Sigstore/Cosign) to ensure image integrity.

2. Use authorization plugins to restrict the archive endpoint: Docker AuthZ plugins can block or tightly control access to the PUT /containers/{id}/archive API endpoint, which keeps the vulnerable code path from being triggered.

3. Avoid piping compressed archives into untrusted containers: In particular, do not use docker cp - to pipe xz or gzip-compressed data into containers from untrusted sources. Use uncompressed tar for copy operations where possible.

Affected Systems and Versions

The vulnerability affects the following software:

• Docker Engine: All versions prior to 29.5.1 (including the entire 28.x line and earlier)
• Moby (github.com/moby/moby): All versions up to and including 28.5.2
• Moby v2 (github.com/moby/moby/v2): All versions prior to 2.0.0-beta.14
• Docker (github.com/docker/docker): All versions up to and including 28.5.2 (legacy module path)

The Chainguard vulnerability tracker also lists CVE-2026-41567 as affecting buildah, which indicates that container tools layered on Moby are affected too. The projectdiscovery/nuclei issue tracker flags it as an open CVE in docker/docker v28.3.3.

Organizations running Mirantis Container Runtime (MCR), which tracks the upstream Moby project, should watch the Mirantis release notes for a corresponding fix. MCR has historically released security fixes that correspond to Docker Engine vulnerabilities.

Vulnerable Configurations

A system is vulnerable when all of the following conditions are met:

• Docker Engine is running a version prior to 29.5.1
• A container is running from an image that contains a trojanized xz or unpigz binary on its PATH
• A user uploads an xz-compressed or gzip-compressed archive into that container via PUT /containers/{id}/archive or docker cp -

Vendor Security History

Docker and Moby have a recurring history of vulnerabilities that break the container-to-host trust boundary:

The container-to-host trust boundary has been a persistent attack surface in the Docker ecosystem. The 2024 Leaky Vessels vulnerabilities were exploited rapidly after disclosure, which shows that container escape flaws draw immediate attention from threat actors. CVE-2026-41567 attacks the same boundary through a different mechanism, search path manipulation, rather than file descriptor leaks or authorization logic flaws.

References

• GHSA-x86f-5xw2-fm2r: GitHub Security Advisory
• GHSA-x86f-5xw2-fm2r: GitHub Advisory Database
• Docker Engine Version 29 Release Notes
• GHSA-x86f-5xw2-fm2r on OSV
• Moby/Moby Releases on GitHub
• CVE-2026-41567 on Sonatype Guide
• PT-2026-41765: Positive Technologies Vulnerability Entry
• Nuclei Issue: docker/docker v28.3.3 Open CVEs
• Buildah Vulnerabilities on Chainguard
• CWE-427: Uncontrolled Search Path Element
• CISA Known Exploited Vulnerabilities Catalog
• Docker Security Advisory: Multiple Vulnerabilities in runc, BuildKit, and Moby
• The Moby Project on GitHub
• Moby/Moby Releases API