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

Impact When using a custom BuildKit frontend, the frontend can craft an API message that causes files to be written outside of the BuildKit state directory for the execution context.

Patches The issue has been fixed in v0.28.1+

Workarounds Issue requires using an untrusted BuildKit frontend set with #syntax or --build-arg BUILDKITSYNTAX. Using these options with a well-known frontend image like docker/dockerfile is not affected.

BuildKit's cache mount source= selector on Windows Container on Windows (WCOW) workers does not detect NTFS directory junctions placed inside the cache root. A build authored by an untrusted user on a WCOW-configured BuildKit daemon can read arbitrary host files reachable to the BuildKit daemon process.

A custom client can produce such an upload request to the BuildKit daemon that files can escape from the BuildKit-controlled state directory. The client needs to have valid permissions to access the BuildKit control API to issue builds, e.g., bypass authentication, etc.

A crafted message in the BuildKit low-level build API can be used to remove the contents of the /tmp directory. The action that can normally be used to delete files inside the build container rootfs can escape into the real host temp directory.

A malicious BuildKit client or frontend could craft a request that could lead to BuildKit daemon crashing with a panic.

BuildKit custom frontends or clients using the raw low-level API can set git.checkoutbundle=true when checking out Git sources. If the Git source is malicious, this could lead to a crafted command invocation on the host.

Impact Insufficient validation of Git URL fragment subdir components (<url>#<ref>:<subdir>, docs) may allow access to files outside the checked-out Git repository root. Possible access is limited to files on the same mounted filesystem.

Patches The issue has been fixed in version v0.28.1

Workarounds The issue affects only builds that use Git URLs with a subpath component. Avoid building Dockerfiles from untrusted sources or using the subdir component from an untrusted Git repository where the subdir component could point to a symlink.

Summary

A race condition during docker cp mount setup allows a malicious container to create empty files or directories at arbitrary absolute paths on the host filesystem.

This advisory covers the race during mountpoint creation. The related race during the subsequent mount syscall is tracked in GHSA-rg2x-37c3-w2rh

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 path is first resolved within the container's root filesystem using GetResourcePath, and then used to create the mountpoint (file or directory) if it does not already exist via createIfNotExists.

Between path resolution and mountpoint creation, a process running inside the container can swap a path component for a symlink pointing to an arbitrary location on the host. Because createIfNotExists operates on the already-resolved absolute path using standard os.MkdirAll and os.OpenFile — which follow symlinks in intermediate path components — the symlink is followed and the file or directory is created outside the container root filesystem, as root.

Impact

A malicious container can create empty files or directories at arbitrary absolute paths on the host filesystem, running as root. This enables persistent denial of service — for example:

- Converting /etc/docker/daemon.json into a directory prevents the daemon from restarting - Creating /etc/nologin prevents user logins - Overwriting critical system paths with empty files can break host services

The container does not gain read or write access to existing host files — only the ability to create new empty files or directories at chosen paths.

Conditions for exploitation

- A container must be running with a process that can rapidly create and swap symlinks at a 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.

Patches

Mountpoint creation is now scoped to the container root using os.Root (Go 1.24+), which refuses to follow symlinks that escape the opened root directory. All filesystem operations in createIfNotExists (MkdirAll, OpenFile) are performed through the os.Root handle, so even if a symlink swap occurs after path resolution, the creation stays confined to the container root.

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

Moby could provide weaker than expected security, caused by improper cache validation in the classic builder cache system. By persuading a victim to open a specially crafted file, a remote attacker could exploit this vulnerability to conduct a cache poisoning attack.

Impact A malicious BuildKit client or frontend could craft a request that could lead to BuildKit daemon crashing with a panic.

Patches The issue has been fixed in v0.12.5

Workarounds Avoid using BuildKit frontends from untrusted sources. A frontend image is usually specified as the #syntax line on your Dockerfile, or with --frontend flag when using buildctl build command.

References

Impact Two malicious build steps running in parallel sharing the same cache mounts with subpaths could cause a race condition that can lead to files from the host system being accessible to the build container.

Patches The issue has been fixed in v0.12.5

Workarounds Avoid using BuildKit frontend from an untrusted source or building an untrusted Dockerfile containing cache mounts with --mount=type=cache,source=... options.

References https://www.openwall.com/lists/oss-security/2019/05/28/1

Impact A malicious BuildKit frontend or Dockerfile using RUN --mount could trick the feature that removes empty files created for the mountpoints into removing a file outside the container, from the host system.

Patches The issue has been fixed in v0.12.5

Workarounds Avoid using BuildKit frontend from an untrusted source or building an untrusted Dockerfile containing RUN --mount feature.

References

Impact In addition to running containers as build steps, BuildKit also provides APIs for running interactive containers based on built images. It was possible to use these APIs to ask BuildKit to run a container with elevated privileges. Normally, running such containers is only allowed if special security.insecure entitlement is enabled both by buildkitd configuration and allowed by the user initializing the build request.

Patches The issue has been fixed in v0.12.5 .

Workarounds Avoid using BuildKit frontends from untrusted sources. A frontend image is usually specified as the #syntax line on your Dockerfile, or with --frontend flag when using buildctl build command.

References

Impact

A bug was found in Moby (Docker Engine) where the data directory (typically /var/lib/docker) contained subdirectories with insufficiently restricted permissions, allowing otherwise unprivileged Linux users to traverse directory contents and execute programs. When containers included executable programs with extended permission bits (such as setuid), unprivileged Linux users could discover and execute those programs. When the UID of an unprivileged Linux user on the host collided with the file owner or group inside a container, the unprivileged Linux user on the host could discover, read, and modify those files.

Patches

This bug has been fixed in Moby (Docker Engine) 20.10.9. Users should update to this version as soon as possible. Running containers should be stopped and restarted for the permissions to be fixed.

Workarounds

Limit access to the host to trusted users. Limit access to host volumes to trusted containers.

Credits

The Moby project would like to thank Joan Bruguera for responsibly disclosing this issue in accordance with the Moby security policy.

For more information

If you have any questions or comments about this advisory:

Open an issue Email us at security@docker.com if you think you’ve found a security bug

Impact A bug was found in Moby (Docker Engine) where attempting to copy files using docker cp into a specially-crafted container can result in Unix file permission changes for existing files in the host’s filesystem, widening access to others. This bug does not directly allow files to be read, modified, or executed without an additional cooperating process.

Patches This bug has been fixed in Moby (Docker Engine) 20.10.9. Users should update to this version as soon as possible. Running containers do not need to be restarted.

Workarounds Ensure you only run trusted containers.

Credits The Moby project would like to thank Lei Wang and Ruizhi Xiao for responsibly disclosing this issue in accordance with the Moby security policy.

For more information If you have any questions or comments about this advisory:

Open an issue Email us at  security@docker.com  if you think you’ve found a security bug

Moby is an open source container framework developed by Docker Inc. that is distributed as Docker Engine, Mirantis Container Runtime, and various other downstream projects/products. A firewalld vulnerability affects Moby releases before 28.0.0. When firewalld reloads, Docker fails to re-create iptables rules that isolate bridge networks, allowing any container to access all ports on any other container across different bridge networks on the same host. This breaks network segmentation between containers that should be isolated, creating significant risk in multi-tenant environments. Only containers in --internal networks remain protected. Workarounds include reloading firewalld and either restarting the docker daemon, re-creating bridge networks, or using rootless mode. Maintainers anticipate a fix for this issue in version 25.0.13.

An issue was discovered in Docker Moby before 17.06.0. The Docker engine validated a client TLS certificate using both the configured client CA root certificate and all system roots on non-Windows systems. This allowed a client with any domain validated certificate signed by a system-trusted root CA (as opposed to one signed by the configured CA root certificate) to authenticate.

moby v25.0.0 - v26.0.2 is vulnerable to NULL Pointer Dereference via daemon/images/imagehistory.go.

Last updated 1 May 2025

Last updated 7 May 2025

The DefaultLinuxSpec function in oci/defaults.go in Docker Moby through 17.03.2-ce does not block /proc/scsi pathnames, which allows attackers to trigger data loss (when certain older Linux kernels are used) by leveraging Docker container access to write a "scsi remove-single-device" line to /proc/scsi/scsi, aka SCSI MICDROP.

Moby is an open source container framework developed by Docker Inc. that is distributed as Docker Engine, Mirantis Container Runtime, and various other downstream projects/products. In versions 28.2.0 through 28.3.2, when the firewalld service is reloaded it removes all iptables rules including those created by Docker. While Docker should automatically recreate these rules, versions before 28.3.3 fail to recreate the specific rules that block external access to containers. This means that after a firewalld reload, containers with ports published to localhost (like 127.0.0.1:8080) become accessible from remote machines that have network routing to the Docker bridge, even though they should only be accessible from the host itself. The vulnerability only affects explicitly published ports - unpublished ports remain protected. This issue is fixed in version 28.3.3.

In 26.0.0 and 26.0.1, IPv6 is not disabled on network interfaces, including those belonging to networks where --ipv6=false.

Impact

A container with an ipvlan or macvlan interface will normally be configured to share an external network link with the host machine. Because of this direct access, with IPv6 enabled:

- Containers may be able to communicate with other hosts on the local network over link-local IPv6 addresses. - If router advertisements are being broadcast over the local network, containers may get SLAAC-assigned addresses. - The interface will be a member of IPv6 multicast groups.

This means interfaces in IPv4-only networks present an unexpectedly and unnecessarily increased attack surface.

A container with an unexpected IPv6 address can do anything a container configured with an IPv6 address can do. That is, listen for connections on its IPv6 address, open connections to other nodes on the network over IPv6, or attempt a DoS attack by flooding packets from its IPv6 address. This has CVSS score AV:L/AC:H/PR:N/UI:R/S:C/C:N/I:N/A:L (2.7).

Because the container may not be constrained by an IPv6 firewall, there is increased potential for data exfiltration from the container. This has CVSS score AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N (4.7).

A remote attacker could send malicious Router Advertisements to divert traffic to itself, a black-hole, or another device. The same attack is possible today for IPv4 macvlan/ipvlan endpoints with ARP spoofing, TLS is commonly used by Internet APIs to mitigate this risk. The presence of an IPv6 route could impact the container's availability by indirectly abusing the behaviour of software which behaves poorly in a dual-stack environment. For example, it could resolve a name to a DNS AAAA record and keep trying to connect over IPv6 without ever falling back to IPv4, potentially denying service to the container. This has CVSS score AV:A/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H (4.5).

Patches

The issue is patched in 26.0.2.

Workarounds

To completely disable IPv6 in a container, use --sysctl=net.ipv6.conf.all.disableipv6=1 in the docker create or docker run command. Or, in the service configuration of a compose file, the equivalent:

sysctls: - net.ipv6.conf.all.disableipv6=1

References

- sysctl configuration using docker run: - https://docs.docker.com/reference/cli/docker/container/run/#sysctl - sysctl configuration using docker compose: - https://docs.docker.com/compose/compose-file/compose-file-v3/#sysctls

External DNS requests from 'internal' networks could lead to data exfiltration

Moby is an open-source project created by Docker to enable software containerization. A bug was found in Moby (Docker Engine) where supplementary groups are not set up properly. If an attacker has direct access to a container and manipulates their supplementary group access, they may be able to use supplementary group access to bypass primary group restrictions in some cases, potentially gaining access to sensitive information or gaining the ability to execute code in that container. This bug is fixed in Moby (Docker Engine) 20.10.18. Running containers should be stopped and restarted for the permissions to be fixed. For users unable to upgrade, this problem can be worked around by not using the "USER $USERNAME" Dockerfile instruction. Instead by calling ENTRYPOINT ["su", "-", "user"] the supplementary groups will be set up properly.

A malicious guest can trigger vulnerabilities in the host by abusing certain drivers that may lead to code execution outside the virtualized guest.

A malicious guest can trigger vulnerabilities in the host by abusing certain drivers that may lead to code execution outside the virtualized guest.

A malicious guest can trigger vulnerabilities in the host by abusing certain drivers that may lead to code execution outside the virtualized guest.

A malicious guest can trigger vulnerabilities in the host by abusing certain drivers that may lead to code execution outside the virtualized guest.