CVE-2026-93317 in BuildKit
Summary
by MITRE • 10/05/2026
An unauthenticated attacker controlling a registry or OCI-layout blob source could provide blob contents that did not match the claimed digest. The resulting snapshot could be cached under that digest and reused by a later victim build, compromising build-input integrity.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/05/2026
The vulnerability described constitutes a critical failure in content-addressable storage verification within container image building systems such as BuildKit or similar OCI-compliant tools. In standard container workflows, images are composed of layers identified by cryptographic digests, typically SHA-256 hashes. The fundamental security assumption is that the digest uniquely identifies the blob's contents, ensuring integrity and reproducibility. However, this flaw allows an unauthenticated attacker who controls a registry or an OCI-layout blob source to serve malicious content while advertising a legitimate, expected digest. This discrepancy arises because the system fails to strictly validate that the retrieved payload matches the claimed hash before caching it for subsequent use.
From a technical perspective, the core issue lies in the race condition or logic error during the fetch and cache verification phase. When a build process requests an image layer, it typically checks if the blob is already present in the local cache under the specified digest. If found, the system may skip re-downloading to save bandwidth and time. In this vulnerable scenario, the attacker pre-populates the cache or intercepts the request such that the cached object bears the correct hash but contains malicious code instead of the intended legitimate source material. Because the verification step is either bypassed, performed incorrectly, or relies on a trusted-but-compromised state, the build system accepts the tampered blob as authentic. This effectively breaks the chain of trust from the registry to the final container image.
The operational impact of this vulnerability is severe, leading directly to supply chain compromise and loss of build-input integrity. An attacker can inject arbitrary code into a victim's CI/CD pipeline by manipulating the cached layers used during the build process. Since modern builds often rely on reproducible environments where intermediate artifacts are reused across different runs or even different organizations sharing common base images, this attack vector scales rapidly. A single compromised layer in a widely used base image can infect thousands of downstream applications without detection, as the cryptographic hash remains valid from the perspective of the flawed verification logic. This undermines the security guarantees provided by content-addressable storage and allows for stealthy injection of backdoors, data exfiltration mechanisms, or destructive payloads into production environments.
This vulnerability aligns with CWE-345 Insufficient Verification of Data Authenticity, as the system fails to ensure that the received data matches its claimed identity before trusting it. Furthermore, in the context of the MITRE ATT&CK framework for Enterprise, this behavior facilitates Supply Chain Compromise tactics, specifically relating to artifact injection or tampering with build processes. The attacker leverages trust relationships within the container ecosystem to bypass authentication requirements entirely, exploiting the convenience features of caching mechanisms that were not designed with adversarial registry scenarios in mind.
To mitigate this risk, organizations must enforce strict digest verification at every stage of image retrieval and construction. This involves ensuring that clients verify the SHA-256 hash of downloaded blobs against their expected values before writing them to any cache or using them for layer assembly. Implementing content trust policies via Docker Content Trust or similar mechanisms can add a layer of cryptographic signing validation, although this primarily addresses authenticity rather than integrity if the key infrastructure is compromised. Additionally, build systems should be configured to invalidate caches when there are discrepancies between expected and actual digests, forcing re-download from verified sources. Regular auditing of registry configurations and ensuring that caching layers are isolated per user or project can also reduce the blast radius of such attacks by preventing cross-tenant contamination through shared cache stores.