Buildkit
Monthly
Cache poisoning in BuildKit lets a malicious image advertise DiffIDs that do not match its actual layer contents, so a daemon with a shared or persistent cache can adopt attacker-controlled layers as the base for a victim image and execute attacker code inside the victim build - for example by replacing a commonly executed path such as /bin/sh, reading build secrets mounted into the build, altering output artifacts, or hanging the build. Exploitation is unauthenticated but conditional: the attacker's image must be processed before the victim build on a daemon with a shared or persistent cache (multi-tenant or long-lived CI/build farms), and a victim build must then reference the targeted base image; ephemeral, non-shared caches are unaffected. No public exploit code identified at time of analysis; the vendor patch is BuildKit v0.33.1, and the issue carries a CVSS 7.5 (CVSS 4.0) rating with our independent assessment at CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:L.
Denial of service in Moby BuildKit allows a low-privileged remote user to crash the BuildKit daemon by submitting a build that attempts to use a CDI device when the daemon was started with the --cdi-disabled flag. This triggers a null pointer dereference (CWE-476) and daemon panic. The vulnerability requires a non-default configuration and the ability to submit builds; default deployments are not affected. No public exploit has been identified, and the vendor has released a patch in version 0.33.1.
Argument injection in Moby BuildKit lets a malicious Git source trigger crafted command invocation on the build host when a custom frontend or a client using the raw low-level API enables the non-default git.checkoutbundle=true option during Git source checkout. The flaw affects builds that opt into this experimental checkout behavior rather than standard Dockerfile builds, and a successful attack yields high-impact command execution in the build environment. No public exploit has been identified at time of analysis and it is not listed in CISA KEV.
BuildKit through v0.34.0 lets a client holding access to the daemon's control API set an extended attribute on a file outside the BuildKit state directory, including attributes in the trusted. and security. namespaces, which can leave a program on the host with more privilege than it should have. The flaw is genuine but conditional: the vector is local with high privileges required (a legitimate control-API client), so only build services that accept build requests from untrusted users - multi-tenant or hosted CI build backends - are realistically exposed, while default single-user Docker builds are not. No public exploit code has been identified at time of analysis and there is no confirmed active exploitation (CISA KEV); the vendor fix is v0.34.1.
Moby BuildKit (all versions in the affected range per the unbounded CPE cpe:2.3:a:moby:buildkit:*:*:*:*:*:*:*:*) can be made to run its cleanup routine against a modified CA bundle when proxy networking with CA injection is enabled, a time-of-check-to-time-of-use (CWE-367) race that causes cleanup to block, operate outside the build rootfs, or fail without failing the build. The attacker must be able to submit or execute a build on the builder (local, low-privilege access; PR:L) and must first change the build's injected CA bundle before cleanup runs; the non-default proxy-with-CA-injection mode sharply narrows exposed deployments, and the dominant consequence is availability and integrity of the cleanup operation (VA:H, VI:L) rather than confidentiality loss. No public exploit code was identified at time of analysis and the issue is not in CISA KEV; vendor-released patch v0.33.1 is available.
BuildKit (moby/buildkit) contains a policy-validation bypass in which a specially crafted Git source build step makes a repository appear to originate from a different remote URL than the one actually used during git clone, so repository-identity or URL-based policy rules can be evaded. The issue affects BuildKit builds prior to v0.33.1 and requires an attacker to hold build-submission privileges (CVSS vector PR:L); policies that validate commit SHA, commit data, or cryptographic signatures continue to apply correctly, which limits the practical impact (vendor CVSS 4.0 base 6.0, independent assessment 3.1 base with AC:H, low confidentiality and high integrity impact, no availability impact). No public exploit code and no confirmed active exploitation (CISA KEV) were identified at time of analysis; the vendor reports a patch is available.
Denial of service in the BuildKit Dockerfile frontend (buildkitd) allows a user who can submit a build context to exhaust the daemon's memory and terminate it by placing an oversized Dockerfile or .dockerignore file in that context, because these files were loaded into memory without any size limit (CWE-789). The assessed vector (AV:L/PR:L) indicates low-privilege, local/context-level access is required to submit the build, so the practical risk is concentrated on shared or multi-tenant buildkitd instances such as CI/CD pipelines and hosted build services, where one submitter's crash interrupts other users' builds, while a single-user workstation daemon only harms its own environment. Impact is bounded to availability with no code execution, data disclosure, or integrity impact, no public exploit code or CISA KEV confirmation was identified at time of analysis, and the vendor has released BuildKit v0.33.1, which rejects such files above 16 MiB.
Denial of service in Moby BuildKit allows anyone able to submit an LLB build definition to a buildkitd daemon to panic and terminate the daemon process, aborting every build running on that instance. The flaw is an out-of-bounds array index (CWE-129) reached during processing of an attacker-controlled low-level build graph, and it affects all BuildKit releases prior to v0.33.1, including BuildKit embedded in Docker Engine and CI/build-service deployments. The assessed impact is availability-only (CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 6.9), the attack surface is the local build API/daemon socket rather than arbitrary network exposure, and severity scales with multi-tenancy - a shared CI runner or multi-tenant build service loses all concurrent builds from a single crafted definition. Vendor patch v0.33.1 is available; no public exploit code was identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV).
BuildKit, the container build engine used by Docker and exposed through `docker build`/buildx, can be tricked into performing file operations on special file inodes - device nodes, FIFOs, or sockets - at paths where it expects ordinary regular files, a confused-deputy condition (CWE-441). A user who builds an attacker-controlled Dockerfile or build context can therefore cause build operations to hang/block, and on rootful workers can obtain unintended access to host devices; rootless configurations are effectively limited to availability and integrity effects. The attack is local and requires the victim to actively run a build on the malicious input, so exposure concentrates in multi-tenant or untrusted-source CI/CD pipelines that use rootful BuildKit workers; no public exploit has been identified at time of analysis and the flaw is not in CISA KEV. This is best treated as a medium-severity, defense-in-depth hardening issue rather than an urgent remote-exploitation priority.
A malicious external BuildKit frontend can issue crafted requests against the daemon's internal API that trigger a data race, causing the BuildKit daemon to panic and crash. The issue affects BuildKit deployments where the operator has opted into running an untrusted or attacker-controlled frontend (for example through a `# syntax=` reference to a third-party image); default builds that use trusted first-party frontends are not exposed. It is a medium-severity denial-of-service condition: exploitation requires low-level privileges (PR:L) through the frontend channel, local access (AV:L), and successful timing of a race (AT:P), and there is no public exploit identified at time of analysis. A vendor fix is available in BuildKit v0.33.1.
BuildKit can cache a fetched snapshot under a claimed content digest without adequately verifying that the blob bytes match that digest, letting an attacker who controls or compromises a registry or OCI-layout blob source poison the cache and compromise the integrity of later victim builds that reuse that digest. The attacker does not need credentials per the CVSS PR:N vector, but they must be able to serve BuildKit blob requests, and a victim must run a build against the attacker-influenced source for exploitation to matter. No public exploit was identified at time of analysis; vendor patch v0.33.1 is available, and an independent assessment rates this as a moderate, conditions-dependent integrity flaw rather than a drop-everything emergency.
Denial of service in Docker BuildKit (moby/buildkit) allows a malicious or compromised client or frontend to crash the BuildKit daemon (buildkitd) by sending a specially crafted request that triggers an unhandled Go panic. The vulnerability affects all versions of moby/buildkit (CPE cpe:2.3:a:moby:buildkit:*). Any authenticated BuildKit client or frontend - including those operating in CI/CD pipelines, Kubernetes build nodes, or Docker Desktop environments - with network access to the daemon can exploit this to disrupt all concurrent and subsequent build operations. No public exploit is identified at time of analysis and the vulnerability has not been added to the CISA KEV catalog.
Path traversal in BuildKit's low-level build API allows crafted messages to redirect the container rootfs file-deletion action onto the real host /tmp directory, wiping its contents. All published moby/buildkit versions are affected per the broad CPE cpe:2.3:a:moby:buildkit:*:*:*:*:*:*:*:*. No public exploit code or active exploitation has been identified at time of analysis; the vendor-assigned CVSS score of 3.3 (CVSS 4.0) correctly reflects a constrained impact - host /tmp destruction rather than arbitrary code execution or credential exposure.
Path traversal in the BuildKit daemon allows a client with valid control API access to craft a malicious upload request that writes files outside the BuildKit-controlled state directory, breaking container build sandbox boundaries. Affected products span all tracked versions of moby/buildkit per CPE data, and the vulnerability carries a CVSS 4.0 score of 6.9 with high integrity and availability impact on the vulnerable system. No public exploit code or CISA KEV listing has been identified at time of analysis.
Arbitrary host file disclosure in BuildKit's WCOW (Windows Container on Windows) worker mode allows an untrusted build author to read any file reachable by the BuildKit daemon process. By placing NTFS directory junctions inside the cache mount root - a technique the `source=` selector fails to detect on Windows - a malicious Dockerfile can redirect cache access to traverse outside the container's expected filesystem boundary. This affects any multi-tenant or shared CI/CD environment running a WCOW-configured BuildKit daemon where untrusted users can submit builds; no active exploitation has been confirmed (not listed in CISA KEV) and no public exploit code has been identified at time of analysis.
BuildKit is a toolkit for converting source code to build artifacts in an efficient, expressive and repeatable manner. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
Cache poisoning in BuildKit lets a malicious image advertise DiffIDs that do not match its actual layer contents, so a daemon with a shared or persistent cache can adopt attacker-controlled layers as the base for a victim image and execute attacker code inside the victim build - for example by replacing a commonly executed path such as /bin/sh, reading build secrets mounted into the build, altering output artifacts, or hanging the build. Exploitation is unauthenticated but conditional: the attacker's image must be processed before the victim build on a daemon with a shared or persistent cache (multi-tenant or long-lived CI/build farms), and a victim build must then reference the targeted base image; ephemeral, non-shared caches are unaffected. No public exploit code identified at time of analysis; the vendor patch is BuildKit v0.33.1, and the issue carries a CVSS 7.5 (CVSS 4.0) rating with our independent assessment at CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:L.
Denial of service in Moby BuildKit allows a low-privileged remote user to crash the BuildKit daemon by submitting a build that attempts to use a CDI device when the daemon was started with the --cdi-disabled flag. This triggers a null pointer dereference (CWE-476) and daemon panic. The vulnerability requires a non-default configuration and the ability to submit builds; default deployments are not affected. No public exploit has been identified, and the vendor has released a patch in version 0.33.1.
Argument injection in Moby BuildKit lets a malicious Git source trigger crafted command invocation on the build host when a custom frontend or a client using the raw low-level API enables the non-default git.checkoutbundle=true option during Git source checkout. The flaw affects builds that opt into this experimental checkout behavior rather than standard Dockerfile builds, and a successful attack yields high-impact command execution in the build environment. No public exploit has been identified at time of analysis and it is not listed in CISA KEV.
BuildKit through v0.34.0 lets a client holding access to the daemon's control API set an extended attribute on a file outside the BuildKit state directory, including attributes in the trusted. and security. namespaces, which can leave a program on the host with more privilege than it should have. The flaw is genuine but conditional: the vector is local with high privileges required (a legitimate control-API client), so only build services that accept build requests from untrusted users - multi-tenant or hosted CI build backends - are realistically exposed, while default single-user Docker builds are not. No public exploit code has been identified at time of analysis and there is no confirmed active exploitation (CISA KEV); the vendor fix is v0.34.1.
Moby BuildKit (all versions in the affected range per the unbounded CPE cpe:2.3:a:moby:buildkit:*:*:*:*:*:*:*:*) can be made to run its cleanup routine against a modified CA bundle when proxy networking with CA injection is enabled, a time-of-check-to-time-of-use (CWE-367) race that causes cleanup to block, operate outside the build rootfs, or fail without failing the build. The attacker must be able to submit or execute a build on the builder (local, low-privilege access; PR:L) and must first change the build's injected CA bundle before cleanup runs; the non-default proxy-with-CA-injection mode sharply narrows exposed deployments, and the dominant consequence is availability and integrity of the cleanup operation (VA:H, VI:L) rather than confidentiality loss. No public exploit code was identified at time of analysis and the issue is not in CISA KEV; vendor-released patch v0.33.1 is available.
BuildKit (moby/buildkit) contains a policy-validation bypass in which a specially crafted Git source build step makes a repository appear to originate from a different remote URL than the one actually used during git clone, so repository-identity or URL-based policy rules can be evaded. The issue affects BuildKit builds prior to v0.33.1 and requires an attacker to hold build-submission privileges (CVSS vector PR:L); policies that validate commit SHA, commit data, or cryptographic signatures continue to apply correctly, which limits the practical impact (vendor CVSS 4.0 base 6.0, independent assessment 3.1 base with AC:H, low confidentiality and high integrity impact, no availability impact). No public exploit code and no confirmed active exploitation (CISA KEV) were identified at time of analysis; the vendor reports a patch is available.
Denial of service in the BuildKit Dockerfile frontend (buildkitd) allows a user who can submit a build context to exhaust the daemon's memory and terminate it by placing an oversized Dockerfile or .dockerignore file in that context, because these files were loaded into memory without any size limit (CWE-789). The assessed vector (AV:L/PR:L) indicates low-privilege, local/context-level access is required to submit the build, so the practical risk is concentrated on shared or multi-tenant buildkitd instances such as CI/CD pipelines and hosted build services, where one submitter's crash interrupts other users' builds, while a single-user workstation daemon only harms its own environment. Impact is bounded to availability with no code execution, data disclosure, or integrity impact, no public exploit code or CISA KEV confirmation was identified at time of analysis, and the vendor has released BuildKit v0.33.1, which rejects such files above 16 MiB.
Denial of service in Moby BuildKit allows anyone able to submit an LLB build definition to a buildkitd daemon to panic and terminate the daemon process, aborting every build running on that instance. The flaw is an out-of-bounds array index (CWE-129) reached during processing of an attacker-controlled low-level build graph, and it affects all BuildKit releases prior to v0.33.1, including BuildKit embedded in Docker Engine and CI/build-service deployments. The assessed impact is availability-only (CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 6.9), the attack surface is the local build API/daemon socket rather than arbitrary network exposure, and severity scales with multi-tenancy - a shared CI runner or multi-tenant build service loses all concurrent builds from a single crafted definition. Vendor patch v0.33.1 is available; no public exploit code was identified at time of analysis and the issue is not confirmed actively exploited (CISA KEV).
BuildKit, the container build engine used by Docker and exposed through `docker build`/buildx, can be tricked into performing file operations on special file inodes - device nodes, FIFOs, or sockets - at paths where it expects ordinary regular files, a confused-deputy condition (CWE-441). A user who builds an attacker-controlled Dockerfile or build context can therefore cause build operations to hang/block, and on rootful workers can obtain unintended access to host devices; rootless configurations are effectively limited to availability and integrity effects. The attack is local and requires the victim to actively run a build on the malicious input, so exposure concentrates in multi-tenant or untrusted-source CI/CD pipelines that use rootful BuildKit workers; no public exploit has been identified at time of analysis and the flaw is not in CISA KEV. This is best treated as a medium-severity, defense-in-depth hardening issue rather than an urgent remote-exploitation priority.
A malicious external BuildKit frontend can issue crafted requests against the daemon's internal API that trigger a data race, causing the BuildKit daemon to panic and crash. The issue affects BuildKit deployments where the operator has opted into running an untrusted or attacker-controlled frontend (for example through a `# syntax=` reference to a third-party image); default builds that use trusted first-party frontends are not exposed. It is a medium-severity denial-of-service condition: exploitation requires low-level privileges (PR:L) through the frontend channel, local access (AV:L), and successful timing of a race (AT:P), and there is no public exploit identified at time of analysis. A vendor fix is available in BuildKit v0.33.1.
BuildKit can cache a fetched snapshot under a claimed content digest without adequately verifying that the blob bytes match that digest, letting an attacker who controls or compromises a registry or OCI-layout blob source poison the cache and compromise the integrity of later victim builds that reuse that digest. The attacker does not need credentials per the CVSS PR:N vector, but they must be able to serve BuildKit blob requests, and a victim must run a build against the attacker-influenced source for exploitation to matter. No public exploit was identified at time of analysis; vendor patch v0.33.1 is available, and an independent assessment rates this as a moderate, conditions-dependent integrity flaw rather than a drop-everything emergency.
Denial of service in Docker BuildKit (moby/buildkit) allows a malicious or compromised client or frontend to crash the BuildKit daemon (buildkitd) by sending a specially crafted request that triggers an unhandled Go panic. The vulnerability affects all versions of moby/buildkit (CPE cpe:2.3:a:moby:buildkit:*). Any authenticated BuildKit client or frontend - including those operating in CI/CD pipelines, Kubernetes build nodes, or Docker Desktop environments - with network access to the daemon can exploit this to disrupt all concurrent and subsequent build operations. No public exploit is identified at time of analysis and the vulnerability has not been added to the CISA KEV catalog.
Path traversal in BuildKit's low-level build API allows crafted messages to redirect the container rootfs file-deletion action onto the real host /tmp directory, wiping its contents. All published moby/buildkit versions are affected per the broad CPE cpe:2.3:a:moby:buildkit:*:*:*:*:*:*:*:*. No public exploit code or active exploitation has been identified at time of analysis; the vendor-assigned CVSS score of 3.3 (CVSS 4.0) correctly reflects a constrained impact - host /tmp destruction rather than arbitrary code execution or credential exposure.
Path traversal in the BuildKit daemon allows a client with valid control API access to craft a malicious upload request that writes files outside the BuildKit-controlled state directory, breaking container build sandbox boundaries. Affected products span all tracked versions of moby/buildkit per CPE data, and the vulnerability carries a CVSS 4.0 score of 6.9 with high integrity and availability impact on the vulnerable system. No public exploit code or CISA KEV listing has been identified at time of analysis.
Arbitrary host file disclosure in BuildKit's WCOW (Windows Container on Windows) worker mode allows an untrusted build author to read any file reachable by the BuildKit daemon process. By placing NTFS directory junctions inside the cache mount root - a technique the `source=` selector fails to detect on Windows - a malicious Dockerfile can redirect cache access to traverse outside the container's expected filesystem boundary. This affects any multi-tenant or shared CI/CD environment running a WCOW-configured BuildKit daemon where untrusted users can submit builds; no active exploitation has been confirmed (not listed in CISA KEV) and no public exploit code has been identified at time of analysis.
BuildKit is a toolkit for converting source code to build artifacts in an efficient, expressive and repeatable manner. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.