CVE-2026-93322 in BuildKit
Summary
by MITRE • 10/05/2026
A malicious frontend can submit an LLB definition that causes buildkitd to panic and terminate, interrupting all builds running on that daemon.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/05/2026
The vulnerability described constitutes a critical availability risk within the BuildKit ecosystem, specifically targeting the buildkitd daemon through malformed or maliciously crafted Low-Level Builder (LLB) definitions submitted by untrusted frontend clients. In containerized development and continuous integration environments, BuildKit serves as the core engine responsible for parsing instructions from Dockerfiles or direct LLB specifications to construct OCI-compliant images. The architecture relies on a client-server model where frontends submit build requests that are processed asynchronously by the daemon. When an attacker controls the frontend interface, they can inject specially crafted LLB definitions designed to trigger internal logic errors within the Go runtime of the buildkitd process. This results in a panic condition, causing the daemon to terminate abruptly and unexpectedly.
From a technical perspective, this flaw represents a failure in input validation and error handling at the protocol level. The LLB definition is an intermediate representation that dictates how image layers are built, including dependencies, file operations, and environment configurations. A malicious actor can exploit weaknesses in how buildkitd parses specific node types or edge cases within these definitions to trigger unhandled exceptions. Because Go panics typically result in immediate goroutine termination without graceful recovery mechanisms for the main daemon process, this leads to a complete service outage. The impact is severe as it does not merely affect the single malicious build but interrupts all concurrent builds running on that specific daemon instance. This creates a denial-of-service scenario where legitimate development workflows are halted until the daemon is manually restarted and potentially restored from backups if state was corrupted during the crash.
This vulnerability aligns with CWE-20, Improper Input Validation, as the system fails to adequately sanitize or validate the structure of incoming LLB definitions before processing them. Furthermore, it maps directly to MITRE ATT&CK technique T1499, Endpoint Denial of Service, specifically under the sub-category of Resource Exhaustion: Crash/DoS via Application Logic Flaw. The attacker leverages application logic weaknesses rather than resource consumption metrics like CPU or memory limits to achieve system instability. In a multi-tenant CI/CD environment where multiple teams share build infrastructure, this vulnerability allows a single compromised account or malicious insider to disrupt the entire pipeline, causing significant operational delays and potential financial loss due to halted deployments.
Mitigation strategies must focus on isolating untrusted inputs and enforcing strict validation rules before they reach the core processing engine. Organizations should implement network-level controls such as Web Application Firewalls (WAFs) that inspect incoming build requests for known malicious patterns or anomalous LLB structures. Additionally, deploying BuildKit in a sandboxed environment with resource limits can help contain the blast radius of any potential crashes. It is critical to apply all available security patches and updates from the Moby/BuildKit project immediately upon release, as these often include fixes for parser vulnerabilities and improved error handling mechanisms that prevent panics from terminating the daemon. For high-security environments, consider running build processes in isolated containers with limited privileges rather than using a shared persistent daemon, thereby ensuring that a crash in one instance does not affect others or require manual intervention to restore service availability.