CVE-2026-93318: 
Docker vulnerability analysis and mitigation

CVE-2026-93318 is a cache poisoning vulnerability in Moby BuildKit caused by improper validation of image layer DiffIDs. A malicious image can advertise DiffIDs belonging to a different (victim) image while containing entirely different layer contents; BuildKit uses these advertised DiffIDs to derive cache and snapshot identity without verifying they match the actual layer data. All versions of github.com/moby/buildkit up to and including v0.33.0 are affected; the issue was fixed in v0.33.1. It carries a CVSS v4.0 base score of 7.5 (High) (GitHub Advisory, BuildKit Release).

The root cause is CWE-354 (Improper Validation of Integrity Check Value): BuildKit trusted the DiffID values advertised in an image manifest to derive cache keys and snapshot identities without cryptographically verifying that those DiffIDs matched the actual content of the pulled layers. An attacker crafts a malicious OCI/Docker image whose manifest lists DiffIDs copied from a legitimate victim image but whose layer tarballs contain attacker-controlled content. When a BuildKit daemon with a shared or persistent cache processes this malicious image first, the poisoned snapshot is stored under the victim image's DiffID-derived key. A subsequent build that legitimately pulls the victim image then mounts the attacker-controlled layer as its base. The vulnerability affects both regular snapshotters and lazy-pulling snapshotters (e.g., stargz) (GitHub Advisory).

Successful exploitation allows attacker-controlled code to execute within a victim's build environment. Because the malicious layer can replace commonly executed paths such as /bin/sh, the attacker's code runs during the victim's build steps and can read build secrets mounted into the build, access other build resources, alter output artifacts (supply-chain tampering), or hang the build entirely. Confidentiality and integrity of the vulnerable build system are both rated High, with a Low availability impact (GitHub Advisory).

As of the time of disclosure, no public proof-of-concept exploit code or in-the-wild exploitation has been reported; the EPSS score is 0.0 and the NVD SSVC assessment lists exploitation as "none" (GitHub Advisory). Exploitation requires an attacker-controlled image to be processed by the target BuildKit daemon before the victim image is built (Attack Requirements: Present), and active user interaction (a build must be triggered using the victim image). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. The reporter credited is "ktock" (GitHub Advisory).

1. Craft a malicious image: Create an OCI/Docker image whose manifest advertises DiffIDs copied from a known victim base image (e.g., ubuntu:24.04) but whose actual layer tarballs contain attacker-controlled content — for example, a trojanized /bin/sh binary.
2. Push the malicious image: Publish the crafted image to a registry accessible by the target BuildKit daemon (e.g., a public registry or one the target CI/CD pipeline pulls from).
3. Trigger processing of the malicious image: Cause the target BuildKit daemon (which uses a shared or persistent cache) to pull and process the malicious image — for example, by submitting a build job that references it as a base image or by any other mechanism that causes the daemon to fetch it.
4. Poison the cache: BuildKit stores the attacker-controlled layer snapshot under the victim image's DiffID-derived cache key without validating the content hash.
5. Wait for a victim build: When a legitimate user triggers a build using the real victim base image, BuildKit finds the poisoned cache entry and mounts the attacker-controlled layer as the base.
6. Execute attacker code: The trojanized binary (e.g., /bin/sh) runs during the victim's build steps, enabling the attacker to exfiltrate build secrets, modify output artifacts, or disrupt the build (GitHub Advisory).

• File System: Unexpected or modified binaries in base image layer snapshots within the BuildKit snapshot store (e.g., altered /bin/sh or other common executables); snapshot directories whose content hash does not match the expected DiffID.
• Logs: BuildKit daemon logs showing cache hits for a base image layer that was sourced from an unexpected or unfamiliar image reference; build logs showing execution of unexpected commands during base image setup steps.
• Process: Unusual child processes spawned during build steps that are inconsistent with the Dockerfile instructions (e.g., network calls, file writes outside expected paths).
• Network: Outbound connections from the build environment to unexpected external hosts during build execution, potentially indicating secret exfiltration (GitHub Advisory).

Upgrade BuildKit to v0.33.1 or later, which validates applied image layer DiffIDs and binds lazy stargz snapshots to their verified TOC digest, ensuring image source cache keys no longer rely on unverified DiffIDs (BuildKit Release). If immediate upgrade is not possible, the following workarounds reduce risk: do not share BuildKit daemon cache between trusted and untrusted builds; use isolated BuildKit daemons or ephemeral builders for untrusted image sources; and prune the BuildKit cache after processing any untrusted images. Note that disabling stargz alone is not sufficient, as regular snapshotters are also affected (GitHub Advisory).