What is the CVSS score of EUVD-2026-36528?

EUVD-2026-36528 has a CVSS 3.1 base score of 7.2 (High). CVSS vector: CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:C/C:N/I:H/A:H. EPSS exploitation probability: 0.0%.

Which versions of Docker Engine are affected by EUVD-2026-36528?

A symlink-based race condition in Docker Engine (through version 28.5.2) permits containers with volume mounts to redirect bind-mount targets to arbitrary host filesystem paths during docker cp…. A patch is available.

How to fix or mitigate EUVD-2026-36528?

24 hours: Inventory Docker/Moby versions across infrastructure and document which deployments accept untrusted containers; audit volume mount configurations. 7 days: Restrict docker cp and archive API operations to trusted containers only; implement role-based access controls on these operations. 30 days: Upgrade Docker/Moby to v2 line (Moby 2.0.0-beta.14 or later) where feasible, or maintain persistent compensating controls if v2 migration is not immediately viable.

Docker Engine EUVD-2026-36528

| CVE-2026-42306 HIGH

UNIX Symbolic Link (Symlink) Following (CWE-61)

2026-05-18 https://github.com/moby/moby

GHSA-rg2x-37c3-w2rh

Docker Denial Of Service Suse

7.2

CVSS 3.1 · NVD

Severity by source

NVD PRIMARY

7.2 HIGH

AV:L/AC:H/PR:L/UI:R/S:C/C:N/I:H/A:H

SUSE

HIGH

qualitative

Primary rating from NVD.

CVSS VectorNVD

CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:C/C:N/I:H/A:H

Attack Vector

Local

Attack Complexity

High

Privileges Required

Low

User Interaction

Required

Scope

Changed

Confidentiality

None

Integrity

High

Availability

High

Lifecycle Timeline

Source Code Evidence Fetched

May 18, 2026 - 18:32 vuln.today

Analysis Generated

May 18, 2026 - 18:32 vuln.today

DescriptionNVD

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

AnalysisAI

Symlink-based race condition in Docker Engine's docker cp implementation allows a malicious container with at least one volume mount to redirect a bind mount to an arbitrary host filesystem path, enabling host file overwrite or temporary denial of service. The flaw affects Moby/Docker through 28.5.2 and is fixed only in the Moby v2 line (2.0.0-beta.14); no public exploit identified at time of analysis. Exploitation requires an operator-initiated docker cp or archive API call against the malicious container, which constrains real-world abuse to environments where untrusted containers receive file copies.

Technical ContextAI

The vulnerability lives in the Moby/Docker daemon (github.com/moby/moby, github.com/docker/docker, and the new github.com/moby/moby/v2 module) inside the docker cp archive code path, which constructs a private mount namespace and bind-mounts container volumes into a transient filesystem view before reading or writing files. The classic TOCTOU pattern manifests because the daemon creates the mount destination inside the container rootfs and then resolves it to an absolute host path before invoking the mount(2) syscall - and mount(2) follows symlinks on its target argument. This is precisely CWE-61 (UNIX Symbolic Link Following): a privileged process operates on a path under control of an unprivileged process, leaving a window in which the container can swap the target (or any parent component) for a symlink pointing anywhere on the host, including sensitive locations such as /etc, /root, or systemd unit directories.

RemediationAI

Upstream fix available (commit/release on the v2 line); the only vendor-released patched version identified is github.com/moby/moby/v2 2.0.0-beta.14, so operators on the GA 1.x/28.x Docker Engine line should track the Moby advisory GHSA-rg2x-37c3-w2rh (https://github.com/moby/moby/security/advisories/GHSA-rg2x-37c3-w2rh) for a backported release before upgrading production hosts. Until a stable patch is available, restrict use of docker cp against untrusted or long-running containers, run only images from trusted sources, and deploy an authorization plugin (AuthZ) that blocks or gates the PUT /containers/{id}/archive and HEAD /containers/{id}/archive endpoints - note that AuthZ plugins add operational overhead and can break tooling such as IDE remote-container workflows or CI pipelines that rely on archive APIs. Operators of multi-tenant or shared Docker hosts should additionally avoid scripting automated docker cp flows that touch containers running untrusted workloads, since user-interaction is the gating step that triggers the race.