| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A build step for a Git source, crafted in a specific way, can bypass some policy validation rules. A malicious build definition can make the repository look like it is coming from a different remote URL than it really is when Git clone is happening. If policy is doing more stricter validation, for example based on commit SHA, commit data, or signatures, then all these validations still apply correctly. |
| A malicious frontend can submit an LLB definition that causes buildkitd
to panic and terminate, interrupting all builds running on that daemon. |
| When proxy networking with CA injection is enabled, a build can modify its CA bundle before cleanup. This may cause cleanup to block, operate outside the build rootfs, or fail without failing the build. |
| A malicious external BuildKit frontend can send requests using the internal API that can create conditions for a data race that can cause the BuildKit daemon to panic. |
| The Dockerfile frontend loaded the Dockerfile and .dockerignore files of a build context into memory without a size limit. A build context containing an oversized file could make buildkitd allocate memory proportional to that file, potentially exhausting memory and terminating the daemon, which interrupts other builds on the same instance. Fixed by rejecting such files above 16 MiB. |
| A malicious image can advertise DiffIDs from another image while containing different layer contents. In affected versions, BuildKit could use the advertised DiffIDs to derive cache and snapshot identity without validating that they matched the actual layer contents.
If a BuildKit daemon with shared or persistent cache first processes such a malicious image, a later build using the victim image may mount the attacker-controlled layer contents as the base image. This can allow code from the malicious image to run in the victim build, for example by replacing a commonly executed path such as /bin/sh. The attacker-controlled code may read build secrets mounted into the build, access other build resources, alter output artifacts, or hang the build.
The issue affects both regular snapshotters and lazy-pulling snapshotters such as stargz. |
| A malicious frontend can submit an LLB definition that causes buildkitd
to panic and terminate, interrupting all builds running on that daemon. |
| BuildKit may be tricked into performing file actions with special file inodes where regular files are expected. Special files may block operations or, on rootful workers, allow unintended host device access. |
| An unauthenticated attacker controlling a registry or OCI-layout blob source could provide blob contents that did not match the claimed digest. The resulting snapshot could be cached under that digest and reused by a later victim build, compromising build-input integrity. |
| If BuildKit daemon is started with --cdi-disabled it can lead to daemon panic when builds try to use CDI devices. This can happen maliciously or by accident. |
| The tar extraction routines in moby/go-archive (Unpack, UnpackLayer, Untar/UntarUncompressed, and the ApplyLayer helpers) do not confine filesystem operations to the destination directory. The extractor decides where each archive entry lands using lexical string checks and then performs the filesystem operation on a path that is resolved by the OS, so links introduced by the archive can be followed out of the destination directory. An attacker who controls the contents of an archive can create or overwrite files at arbitrary paths writable by the extracting process. |
| BuildKit is a toolkit for converting source code to build artifacts in an efficient, expressive and repeatable manner. Prior to 0.31.2, 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 BuildKit control API to issue builds, eg., bypass authentication, etc. This issue is fixed in version 0.31.2. |
| BuildKit is a toolkit for converting source code to build artifacts in an efficient, expressive and repeatable manner. Prior to 0.31.1, BuildKit read attacker-controlled /etc/passwd and /etc/group files without an upper bound while resolving a username to a user identifier or group identifier in executor/oci/user.go and solver/llbsolver/ops/user_linux.go. A malicious base image or build could provide oversized files that exhausted memory during user resolution and caused out-of-memory termination of the buildkitd process. This issue is fixed in version 0.31.1. |
| BuildKit is a toolkit for converting source code to build artifacts in an efficient, expressive and repeatable manner. Prior to 0.31.1, a custom frontend could place an invalid SecurityMode value in a crafted build request, and executor/oci/spec_linux.go treated the unsupported value as a non-sandbox mode without requiring the security.insecure entitlement. This disabled Seccomp and AppArmor protections for the build container even though Linux capabilities remained restricted. This issue is fixed in version 0.31.1. |
| 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. |
| 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. |
| 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. |
| Moby is an open source container framework. In Docker Engine prior to version 29.5.1, Docker Daemon versions 28.5.2 and prior, and Moby Daemon prior to version 2.0.0-beta.14, 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 issue has been patched in Docker Engine version 29.5.1 and Moby Daemon version 2.0.0-beta.14. |
