CVE-2026-93323 in BuildKit
Summary
by MITRE • 10/05/2026
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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/05/2026
The vulnerability identified in Docker BuildKit stems from a lack of input validation regarding the size of context files during the image build process. Specifically, when processing a Dockerfile and its associated .dockerignore file, the system loads these resources into memory without enforcing any upper bounds on their dimensions. This design flaw allows an attacker or a misconfigured build pipeline to supply a build context containing excessively large files. Because BuildKit allocates memory proportional to the size of these input files, processing such oversized inputs triggers unbounded memory consumption within the buildkitd daemon process.
The operational impact of this vulnerability is significant and can lead to a denial-of-service condition for the Docker host environment. As the buildkitd daemon consumes increasing amounts of RAM to accommodate the large file, it may exhaust the available system memory or hit container resource limits imposed by the orchestrator. This exhaustion causes the daemon process to terminate abruptly due to an out-of-memory error. Since BuildKit is often shared across multiple concurrent builds on a single instance, the termination of this central service disrupts all ongoing build operations, leading to widespread interruptions and potential data loss for incomplete builds.
From a security classification perspective, this issue aligns with CWE-789: Memory Excess Allocation, as it involves allocating more memory than is reasonably necessary or bounded by application logic. It also relates to CWE-400: Uncontrolled Resource Consumption, where the system fails to limit the amount of resources consumed during processing. In terms of attack vectors and tactics, this vulnerability can be leveraged in an unauthenticated context if build contexts are accepted from external sources without prior validation, fitting into ATT&CK techniques related to resource exhaustion attacks that aim to degrade service availability rather than compromise confidentiality or integrity directly.
The remediation for this issue involves implementing strict size limits on the files loaded during the build context preparation phase. The fix described restricts the loading of Dockerfile and .dockerignore files to a maximum size of 16 MiB, effectively preventing the unbounded memory allocation that leads to daemon crashes. To further mitigate similar risks in broader DevOps pipelines, organizations should enforce strict input validation on all artifacts submitted for container builds. This includes implementing file size limits at the CI/CD platform level and ensuring that build contexts are sanitized before being passed to the Docker engine. Regular auditing of build scripts and context contents can also help prevent accidental inclusion of large binary files or logs that could trigger similar resource exhaustion issues in other parts of the system.