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 allows a malicious container image to execute arbitrary code with full host root privileges, simply by tricking a user into uploading a compressed archive into the container. CVE-2026-41567 breaks the fundamental container-to-host trust boundary by resolving decompression binaries from the container's filesystem rather than the host's, turning a routine docker cp operation into a privilege escalation vector.

With the Docker container market valued at approximately USD 6.12 billion in 2025 and Docker Engine deployed across virtually every enterprise development and production environment, 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 exists in the Docker daemon's handling of 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, specifically xz for xz-compressed archives and unpigz for gzip-compressed archives.

The critical flaw is an incorrect ordering of operations in the daemon's archive handling logic. Instead of resolving these decompression binaries from the host filesystem (where the daemon runs), the code resolves them from the container's filesystem PATH. This means the container controls which binary the daemon executes.

Because the Docker daemon process runs as host root with unrestricted Linux capabilities, 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 is the key indicator 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 proceeds as follows:

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 malicious 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 occur through two paths:

   • 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, needing to decompress the archive, searches for the decompression binary. Due to the incorrect operation ordering, it resolves the binary from the container's filesystem rather than the host's filesystem.

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

An important nuance for risk assessment: not all docker cp operations or compression formats are vulnerable. The advisory explicitly notes that the following are 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 operations involving xz-compressed or gzip-compressed (via unpigz) archives piped into containers trigger the vulnerable code path. This is because only xz and unpigz decompression requires shelling out to an external binary; the other formats use pure Go implementations that never invoke external processes.

Patch Information

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

The patch corrects the ordering of operations so that decompression binaries are resolved exclusively from the host filesystem before any container filesystem paths are consulted. This eliminates the container-to-host trust boundary violation entirely.

Affected and Patched Versions

For users of Docker Engine directly, upgrading to v29.5.1 or later resolves the issue. The v29.5.1 release was a dedicated security release that 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), addressed a regression introduced by the v29.5.1 security fixes where 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

For downstream consumers relying on the legacy github.com/docker/docker or github.com/moby/moby Go module paths (at versions ≤ 28.5.2), no backported patch exists on those module paths. These users must migrate their dependencies to the github.com/moby/moby/v2 module (v2.0.0-beta.14+) or ensure 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: Restrict container image sources to verified, trusted registries. Implement image signing and verification (e.g., Docker Content Trust, Sigstore/Cosign) to ensure image integrity.

2. Use authorization plugins to restrict the archive endpoint: Deploy Docker AuthZ plugins that block or tightly control access to the PUT /containers/{id}/archive API endpoint. This prevents the vulnerable code path from being triggered.

3. Avoid piping compressed archives into untrusted containers: Specifically avoid docker cp - with piped 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, indicating that container tools layered on Moby are also impacted. The projectdiscovery/nuclei issue tracker specifically flags that docker/docker v28.3.3 carries this as an open CVE.

Organizations running Mirantis Container Runtime (MCR), which tracks the upstream Moby project, should monitor Mirantis release notes for a corresponding fix. MCR has historically released security fixes corresponding 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 experienced a recurring pattern of vulnerabilities that break the container-to-host trust boundary:

This history reveals that the container-to-host trust boundary has been a persistent and recurring attack surface in the Docker ecosystem. The 2024 Leaky Vessels vulnerabilities were exploited rapidly after disclosure, demonstrating that container escape flaws attract immediate threat actor attention. CVE-2026-41567 exploits the same fundamental 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