CVE-2026-93316 in BuildKit
Summary
by MITRE • 10/05/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/05/2026
The vulnerability described involves a critical flaw in the Docker BuildKit daemon's handling of Container Device Interface (CDI) specifications when the daemon is explicitly started with the --cdi-disabled flag. Under normal operational conditions, the CDI specification provides a standardized way to expose hardware devices, such as GPUs or specialized accelerators, to containers without requiring privileged access or complex device node management. However, in this specific configuration scenario, the security controls intended to disable CDI support fail to properly sanitize input requests that attempt to utilize these disabled resources. When a build process initiated by an attacker or triggered accidentally attempts to reference a CDI device despite the global disabling flag, the daemon encounters an unexpected state where it expects no CDI handling but receives instructions requiring such processing. This mismatch in expected versus actual behavior leads to a null pointer dereference or similar memory corruption issue within the Go runtime environment of BuildKit, resulting in an immediate and unhandled panic that crashes the entire build daemon process.
From a technical perspective, this flaw represents a failure in input validation and state management consistency. The vulnerability aligns with CWE-20 Improper Input Validation because the system fails to adequately verify whether incoming resource requests are compatible with the currently active configuration flags before attempting to execute them. Furthermore, it relates to CWE-476 NULL Pointer Dereference if the code path assumes that CDI structures will always be initialized or present when a device request is made, even though they should have been bypassed entirely due to the disabled flag. The operational impact of this vulnerability is significant for environments relying on BuildKit for continuous integration and deployment pipelines. A successful exploitation results in a denial of service against the build infrastructure, as the daemon crash halts all ongoing builds and requires manual restart or recovery procedures. In shared hosting or multi-tenant CI/CD environments, an attacker could exploit this by submitting specially crafted Dockerfiles that request CDI devices, thereby causing repeated crashes of the BuildKit service for other users sharing the same host resources.
This behavior also intersects with MITRE ATT&CK techniques related to Impact and Defense Evasion. Specifically, it can be categorized under T1499 Endpoint Denial of Service where an adversary disrupts availability by exhausting system resources or crashing services. Additionally, if this crash occurs during security scanning builds that rely on BuildKit for container image analysis, the disruption could indirectly aid in defense evasion by preventing the completion of integrity checks. The severity is heightened because the trigger condition requires only a standard build request with specific device annotations, which might be present in legitimate projects using hardware acceleration but inadvertently included in others due to misconfiguration or malicious intent.
Mitigation strategies must focus on both immediate remediation and long-term architectural improvements. Administrators should ensure that BuildKit daemons are updated to the latest stable version where this logic error has been patched by upstream developers, ensuring that requests for disabled CDI devices are gracefully rejected with a clear error message rather than causing a panic. In environments where CDI is not required, it is advisable to enforce strict network-level or API-level controls that prevent non-privileged users from submitting build definitions containing device-specific annotations unless explicitly authorized. Additionally, implementing resource quotas and monitoring for frequent daemon restarts can help detect potential exploitation attempts early. For organizations heavily reliant on hardware-accelerated builds, a more robust approach involves isolating BuildKit instances so that a crash in one instance does not affect the availability of services for other users or critical pipeline stages. Regular auditing of Dockerfile contents to remove unnecessary device requests and validating build configurations against known good baselines can further reduce the attack surface associated with this vulnerability.