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.

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

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.

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.

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

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

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.

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.

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.

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.

Last updated 7 May 2025

Last updated 1 May 2025

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

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

Last updated 1 May 2025

Last updated 1 May 2025

Last updated 1 May 2025

BuildKit is a toolkit for converting source code to build artifacts in an efficient, expressive and repeatable manner. In affected versions when the user sends a build request that contains a Git URL that contains credentials and the build creates a provenance attestation describing that build, these credentials could be visible from the provenance attestation. Git URL can be passed in two ways: 1) Invoking build directly from a URL with credentials. 2) If the client sends additional version control system (VCS) info hint parameters on builds from a local source. Usually, that would mean reading the origin URL from .git/config file. When a build is performed under specific conditions where credentials were passed to BuildKit they may be visible to everyone who has access to provenance attestation. Provenance attestations and VCS info hints were added in version v0.11.0. Previous versions are not vulnerable. In v0.10, when building directly from Git URL, the same URL could be visible in BuildInfo structure that is a predecessor of Provenance attestations. Previous versions are not vulnerable. This bug has been fixed in v0.11.4. Users are advised to upgrade. Users unable to upgrade may disable VCS info hints by setting BUILDXGITINFO=0. buildctl does not set VCS hints based on .git directory, and values would need to be passed manually with --opt.

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.

Impact

A bug was found in Moby (Docker Engine) where containers were incorrectly started with non-empty inheritable Linux process capabilities, creating an atypical Linux environment and enabling programs with inheritable file capabilities to elevate those capabilities to the permitted set during execve(2). Normally, when executable programs have specified permitted file capabilities, otherwise unprivileged users and processes can execute those programs and gain the specified file capabilities up to the bounding set. Due to this bug, containers which included executable programs with inheritable file capabilities allowed otherwise unprivileged users and processes to additionally gain these inheritable file capabilities up to the container's bounding set. Containers which use Linux users and groups to perform privilege separation inside the container are most directly impacted.

This bug did not affect the container security sandbox as the inheritable set never contained more capabilities than were included in the container's bounding set.

Patches

This bug has been fixed in Moby (Docker Engine) 20.10.14. Users should update to this version as soon as possible. Running containers should be stopped, deleted, and recreated for the inheritable capabilities to be reset.

This fix changes Moby (Docker Engine) behavior such that containers are started with a more typical Linux environment. Refer to capabilities(7) for a description of how capabilities work. Note that permitted file capabilities continue to allow for privileges to be raised up to the container's bounding set and that processes may add capabilities to their own inheritable set up to the container's bounding set per the rules described in the manual page. In all cases the container's bounding set provides an upper bound on the capabilities that can be assumed and provides for the container security sandbox.

Workarounds

The entrypoint of a container can be modified to use a utility like capsh(1) to drop inheritable capabilities prior to the primary process starting.

Credits

The Moby project would like to thank Andrew G. Morgan 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

A bug was found in Moby (Docker Engine) where containers were incorrectly started with non-empty inheritable Linux process capabilities, creating an atypical Linux environment and enabling programs with inheritable file capabilities to elevate those capabilities to the permitted set during execve(2). Normally, when executable programs have specified permitted file capabilities, otherwise unprivileged users and processes can execute those programs and gain the specified file capabilities up to the bounding set. Due to this bug, containers which included executable programs with inheritable file capabilities allowed otherwise unprivileged users and processes to additionally gain these inheritable file capabilities up to the container's bounding set. Containers which use Linux users and groups to perform privilege separation inside the container are most directly impacted.

This bug did not affect the container security sandbox as the inheritable set never contained more capabilities than were included in the container's bounding set.

Patches This bug has been fixed in Moby (Docker Engine) 20.10.14. Users should update to this version as soon as possible. Running containers should be stopped, deleted, and recreated for the inheritable capabilities to be reset.

This fix changes Moby (Docker Engine) behavior such that containers are started with a more typical Linux environment. Refer to capabilities(7) for a description of how capabilities work. Note that permitted file capabilities continue to allow for privileges to be raised up to the container's bounding set and that processes may add capabilities to their own inheritable set up to the container's bounding set per the rules described in the manual page. In all cases the container's bounding set provides an upper bound on the capabilities that can be assumed and provides for the container security sandbox.

Workarounds The entrypoint of a container can be modified to use a utility like capsh(1) to drop inheritable capabilities prior to the primary process starting.

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.