BuildKit vulnerabilities

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.

Improper Validation of Specified Quantity in Input vulnerability in VillaTheme BuildKit – Product Builder for WooCommerce – Custom PC Builder woo-product-builder allows Input Data Manipulation.This issue affects BuildKit – Product Builder for WooCommerce – Custom PC Builder: from n/a through 1.0.28.

The Dockerfile frontend loaded Dockerfile and .dockerignore files into memory without a size limit. A build context with an oversized file could cause buildkitd to allocate memory proportional to the file size, potentially exhausting memory and terminating the daemon, interrupting other builds.

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.

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.

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.

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 BuildKit WordPress plugin before 1.0.29 does not properly sanitise and escape data submitted by contributor-level users before storing it and later using it in a SQL query, allowing a Contributor to inject SQL that runs against the database once the resulting content is published and viewed by any unauthenticated visitor.

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, a toolkit for building artifacts, prior to version 0.31.1 has a vulnerability where a custom frontend can place an invalid SecurityMode value in a crafted build request. The executor treats this value as a non-sandbox mode without requiring the security.insecure entitlement, disabling Seccomp and AppArmor protections for the build container while Linux capabilities remain restricted.

Vulnerability in BuildKit allows a malicious Git source, when git.checkoutbundle=true is set, to execute a crafted command on the host during checkout.

A malicious BuildKit client or frontend can craft a request that causes the BuildKit daemon to crash with a panic.

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

Vulnerability in BuildKit. A custom client can send an upload request that allows files to escape from the BuildKit-controlled state directory. Requires valid permissions to access the BuildKit control API.

BuildKit on Windows Container on Windows (WCOW) workers does not detect NTFS directory junctions placed inside the cache root. An untrusted user building an image on a WCOW-configured BuildKit daemon can read arbitrary host files reachable to the daemon process.

BuildKit versions prior to 0.28.1 have insufficient validation of Git URL fragment subdir components, which may allow access to files outside the checked-out Git repository root. Access is limited to files on the same mounted filesystem.