CVE-2026-121522 in BuildKit
Summary
by MITRE • 11/04/2026
In BuildKit versions v0.26.0 through v0.34.1, a specific build definition that resolves metadata for the same Git source reference twice can cause the BuildKit daemon to panic and crash, interrupting builds handled by that daemon. The issue is fixed in v0.34.2.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 11/04/2026
The vulnerability identified within Docker BuildKit versions ranging from v0.26.0 through v0.34.1 represents a critical stability flaw rooted in the handling of Git source metadata resolution during container image construction processes. BuildKit serves as the core engine for building OCI-compliant images, managing complex dependency graphs and build stages. The specific trigger involves a scenario where a single build definition instructs the system to resolve metadata for an identical Git source reference multiple times within the same build context. This redundancy is not merely inefficient but exposes a fundamental flaw in how BuildKit manages state and memory allocation when encountering duplicate references to external version control systems.
At a technical level, this issue manifests as a panic condition that causes the BuildKit daemon process to crash abruptly. The root cause lies in improper handling of concurrent or repeated lookups for Git repository metadata, likely involving race conditions or incorrect assumptions about pointer validity and memory state when the same reference is processed more than once. When the daemon encounters this specific configuration, it fails to gracefully handle the duplicate resolution request, leading to an unrecoverable error that terminates the service. This behavior disrupts any ongoing builds managed by the affected daemon instance, resulting in immediate interruption of CI/CD pipelines and requiring manual intervention or automatic restart mechanisms to restore functionality.
The operational impact of this vulnerability is significant for organizations relying on automated build systems. A crash in BuildKit leads directly to failed build jobs, which can halt software delivery lifecycles if not properly mitigated by upstream retry logic. Furthermore, the unpredictability of such crashes complicates debugging efforts and reduces overall system reliability. In high-throughput environments where builds are frequently triggered, this flaw could lead to resource exhaustion or cascading failures across dependent services that rely on successful image generation. The lack of graceful degradation means that a single malformed build definition can compromise the availability of the entire BuildKit service node.
To mitigate this risk, organizations must ensure their CI/CD infrastructure utilizes Docker BuildKit version v0.34.2 or later, where the underlying logic for handling Git source references has been corrected to prevent the panic condition. For environments unable to upgrade immediately, implementing build definition validation checks can help identify and reject configurations that attempt to resolve the same Git reference multiple times without proper deduplication strategies. Additionally, deploying BuildKit behind a reverse proxy with health checks and automatic restart policies can minimize downtime by quickly recovering from unexpected daemon crashes until a permanent patch is applied. This incident underscores the importance of rigorous input validation and state management in container build tools that interact with external version control systems.