Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹
🐹 Go
Not in CISA KEV
HIGH severity

GHSA-rg2x-37c3-w2rh

HIGH

GHSA-rg2x-37c3-w2rh is a high-severity (CVSS 7.2) CWE-61 vulnerability in github.com/docker/docker. O3 Security confirms whether GHSA-rg2x-37c3-w2rh is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

Docker: Race condition in docker cp allows bind mount redirection to host path

Also known asCVE-2026-42306GO-2026-5617
Published
May 18, 2026
Updated
Jun 25, 2026
Affected
3 pkgs
Patched
1 / 3
Exploits
None indexed
Exploitation data as of Jun 25, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Real-World Exposure

3 pkgs affected
🐹github.com/docker/docker🐹github.com/moby/moby/v2🐹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

A race condition during docker cp mount setup allows a malicious container to redirect a bind mount target to an arbitrary host path, potentially overwriting host files or causing denial of service.

Details

When copying files into a container, the daemon sets up a temporary filesystem view by bind-mounting volumes into a private mount namespace. During this setup, the mount destination is created inside the container root and then a bind mount is attached using the container-relative path resolved to an absolute host path.

Between mountpoint creation and the mount() syscall, a process running inside the container can replace the destination (or a parent path component) with a symlink pointing to an arbitrary location on the host. The mount() syscall follows the symlink, causing the volume to be bind-mounted onto an arbitrary host path instead of the intended container path.

Impact

A malicious container can redirect a volume bind mount to an arbitrary host path. The impact depends on the volume content and mount options:

  • If the volume is writable, arbitrary host files at the redirected path could be overwritten with the volume's contents.
  • If the volume is read-only, the host path is masked by the mount for the duration of the operation, causing denial of service.
  • In all cases the mount is temporary (torn down after the docker cp completes), but the effects of any writes persist.

Conditions for exploitation

  • A container must have at least one volume mount.
  • A process inside the container must be able to rapidly create and swap symlinks at the volume mount destination path.
  • An operator must initiate a docker cp into that container, or call the PUT /containers/{id}/archive or HEAD /containers/{id}/archive API endpoints.

Not affected

  • Containers that do not have volume mounts are not affected, as the race occurs during volume bind-mount setup.

Workarounds

  • Only run containers from trusted images.
  • Avoid using docker cp with untrusted running containers.
  • Use authorization plugins to restrict access to the archive API endpoints (PUT /containers/{id}/archive, HEAD /containers/{id}/archive).

Affected Packages

3 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/docker/dockerall versionsNo fix
🐹Gogithub.com/moby/moby/v2all versions2.0.0-beta.14
🐹Gogithub.com/moby/mobyall versionsNo fix

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/docker/docker. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. Fix

    No patched version of github.com/docker/docker has shipped for GHSA-rg2x-37c3-w2rh yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.

  3. 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.

  4. How O3 protects you

    O3 pinpoints whether GHSA-rg2x-37c3-w2rh is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-rg2x-37c3-w2rh. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

## Summary A race condition during `docker cp` mount setup allows a malicious container to redirect a bind mount target to an arbitrary host path, potentially overwriting host files or causing denial of service. ## Details When copying files into a container, the daemon sets up a temporary filesystem view by bind-mounting volumes into a private mount namespace. During this setup, the mount destination is created inside the container root and then a bind mount is attached using the container-relative path resolved to an absolute host path. Between mountpoint creation and the `mount()` sysca
O3 Security · Impact-Aware SCA

Is GHSA-rg2x-37c3-w2rh in your dependencies?

O3 detects GHSA-rg2x-37c3-w2rh across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.