How severe is GHSA-x86f-5xw2-fm2r?

GHSA-x86f-5xw2-fm2r has a CVSS score of 7.2/10, rated HIGH. Immediate patching is strongly recommended.

Which packages are affected by GHSA-x86f-5xw2-fm2r?

GHSA-x86f-5xw2-fm2r affects the following packages: github.com/moby/moby/v2 (Go), github.com/docker/docker (Go), github.com/moby/moby (Go). Ecosystems affected: Go.

How do I fix GHSA-x86f-5xw2-fm2r?

Update github.com/moby/moby/v2 to 2.0.0-beta.14 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-x86f-5xw2-fm2r is resolved across your whole dependency graph.

How do I detect GHSA-x86f-5xw2-fm2r in my Go dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/moby/moby/v2, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

How do I mitigate GHSA-x86f-5xw2-fm2r if there is no patch (or I can't update yet)?

If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Is GHSA-x86f-5xw2-fm2r actively exploited in the wild?

No public exploit code has been indexed for GHSA-x86f-5xw2-fm2r yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

What is the EPSS score for GHSA-x86f-5xw2-fm2r?

GHSA-x86f-5xw2-fm2r has an EPSS (Exploit Prediction Scoring System) score of 0.2%, placing it in the 5th percentile of all CVEs. EPSS is maintained by FIRST.org and estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. This score indicates relatively lower exploitation probability, though the CVSS severity should still guide your patching priority.

What type of vulnerability is GHSA-x86f-5xw2-fm2r?

GHSA-x86f-5xw2-fm2r is classified as CWE-427 (CWE-427). This weakness type describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation.

When was GHSA-x86f-5xw2-fm2r published, and has it been updated?

GHSA-x86f-5xw2-fm2r was published on May 18, 2026 and was last updated on September 10, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

🐹

🐹 Go

Not in CISA KEV

HIGH severity

GHSA-x86f-5xw2-fm2r — v2

HIGH

GHSA-x86f-5xw2-fm2r is a high-severity (CVSS 7.2) CWE-427 vulnerability in github.com/moby/moby/v2. A fix is available for github.com/moby/moby/v2 — see the affected versions and patch details below.

Docker: `PUT /containers/{id}/archive` executes container binary on the host

Also known asCVE-2026-41567GO-2026-5746

Published

May 18, 2026

Updated

Sep 10, 2026

Affected

3 pkgs

Patched

1 / 3

Exploits

None indexed

Exploitation data as of Sep 26, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

A successful exploit gives an attacker total control of the affected component, not partial access.
CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for GHSA-x86f-5xw2-fm2r.

EPSS Exploitation Probability

via FIRST.org ↗

0.2%probability of exploitation in next 30 days

Lower Risk0.00%

Lower risk than most CVEs5th percentile — riskier than 5% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

GHSA-x86f-5xw2-fm2r by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 379,842 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

3 pkgs affected

🐹github.com/moby/moby/v2🐹github.com/docker/docker🐹github.com/moby/moby

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

Summary

When a user uploads a compressed archive into a container, a malicious image can execute arbitrary code with daemon (host root) privileges.

Details

When handling PUT /containers/{id}/archive requests with compressed archives, the daemon decompresses them using external system binaries. Due to incorrect ordering of operations, these binaries are resolved from the container's filesystem rather than the host's. A container image that includes a trojanized decompression binary can achieve code execution as the daemon process whenever a compressed archive is uploaded to that container.

The executed binary runs with the daemon's full privileges, including host root UID and unrestricted capabilities.

Impact

Arbitrary code execution as host root, crossing the container-to-host trust boundary.

Conditions for exploitation

A user must run a container from a malicious image that contains a trojanized decompression binary.
The user must then upload a compressed archive (xz or gzip) into that container, either by piping a compressed archive via docker cp - or by calling the PUT /containers/{id}/archive API directly with compressed content.

Not affected

Standard docker cp usage is not affected, because the CLI sends uncompressed tar by default:

docker cp ./file.txt mycontainer:/file.txt

This can only be exploited when explicitly passing a xz or gzip-compressed archive to docker cp or the PUT /containers/{id}/archive API, for example:

cat archive.tar.xz | docker cp - mycontainer:/dir

Decompression formats using pure Go implementations (bzip2, zstd, and gzip when the container image does not contain an unpigz binary) are also not affected.

Workarounds

Only run containers from trusted images.
Use authorization plugins to limit access to the PUT /containers/{id}/archive endpoint.
Avoid piping compressed archives into containers created from untrusted images.

Affected Packages

3 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
🐹Go	`github.com/moby/moby/v2`	all versions	2.0.0-beta.14`go get github.com/moby/moby/v2@v2.0.0-beta.14`
🐹Go	`github.com/docker/docker`	all versions	No fix
🐹Go	`github.com/moby/moby`	all versions	No fix

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/moby/moby/v2, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/moby/moby/v2 to 2.0.0-beta.14 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-x86f-5xw2-fm2r is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Fixing This On Your OS

If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.

Red HatImportant

This is an Important vulnerability. A flaw in Moby and Docker Engine allows for arbitrary code execution with host root privileges. This occurs when a user uploads a compressed archive to a container, as the daemon incorrectly uses decompression binaries from the container's filesystem. This could lead to a complete…

Workaround published by Red Hat

To mitigate this issue, Red Hat recommends only running containers from trusted images. Additionally, users should avoid piping compressed archives into containers created from untrusted images. For environments utilizing authorization plugins, restricting access to the `PUT /containers/{id}/archive` endpoint can further reduce exposure.

Source: Red Hat security advisory for GHSA-x86f-5xw2-fm2r (CC BY 4.0)

Product	Fixed in	Advisory
Multicluster Global Hub 1.4.9	`multicluster-globalhub/multicluster-globalhub-grafana-rhel9:1784060681`	RHSA-2026:41030
Multicluster Global Hub 1.6.5	`multicluster-globalhub/multicluster-globalhub-grafana-rhel9:1784561376`	RHSA-2026:44622
OpenShift Developer Tools and Services 1.6.3	`source-to-image/source-to-image-rhel8:1784727697`	RHSA-2026:51057
Red Hat multicluster global hub 1.5.3	`multicluster-globalhub/multicluster-globalhub-grafana-rhel9:1784562060`	RHSA-2026:42852
Red Hat Openshift Data Foundation 4.22	`odf4/cephcsi-rhel9:1782932114`	RHSA-2026:37387

Frequently Asked Questions

## Summary When a user uploads a compressed archive into a container, a malicious image can execute arbitrary code with daemon (host root) privileges. ## Details When handling `PUT /containers/{id}/archive` requests with compressed archives, the daemon decompresses them using external system binaries. Due to incorrect ordering of operations, these binaries are resolved from the container's filesystem rather than the host's. A container image that includes a trojanized decompression binary can achieve code execution as the daemon process whenever a compressed archive is uploaded to that cont