CVE-2026-93319: 
Docker vulnerability analysis and mitigation

CVE-2026-93319 is a denial-of-service vulnerability in moby/buildkit caused by a data race condition that can be triggered by a malicious external BuildKit frontend. A malicious frontend can send requests via the internal API that create race conditions, causing the BuildKit daemon to panic and crash. It affects moby/buildkit versions up to and including v0.33.0, and was disclosed on September 30, 2026, with a patch released the same day. The vulnerability carries a CVSS v3.1 score of 4.7 (Medium) and a CVSS v4.0 score of 5.7 (Medium) (GitHub Advisory, Red Hat).

The root cause is unsynchronized access to shared data in a multithreaded context (CWE-567) and a race condition within a thread (CWE-366). A malicious external BuildKit frontend abuses the internal BuildKit API to trigger gateway container lifecycle races or submit malformed requests and definitions, causing the daemon to encounter an unhandled concurrent state and panic. Exploitation requires local access and low privileges (the ability to deploy or control a BuildKit frontend), and the attack complexity is high due to the timing-dependent nature of race conditions. Dockerfile builds are explicitly noted as unaffected by this issue (GitHub Advisory, Red Hat Bugzilla).

Successful exploitation results in a denial of service by crashing the BuildKit daemon process. The impact is limited to availability — there is no confidentiality or integrity impact, and the vulnerability does not enable code execution, data exfiltration, or lateral movement. Any active build jobs running on the affected daemon would be interrupted, potentially disrupting CI/CD pipelines that depend on BuildKit (GitHub Advisory, Red Hat).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the disclosure date (Red Hat). The EPSS score is 0.0, reflecting very low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Exploitation is non-trivial due to the requirement for local access, low-privilege deployment rights over a BuildKit frontend, and the inherent timing sensitivity of race condition exploitation (GitHub Advisory).

1. Gain access: Obtain local access and sufficient privileges to deploy or control a BuildKit frontend in an environment running a vulnerable BuildKit daemon (v0.33.0 or earlier).
2. Craft a malicious frontend: Develop a custom external BuildKit frontend that sends specially crafted requests to the BuildKit daemon's internal API, targeting gateway container lifecycle operations or submitting malformed LLB definitions.
3. Trigger the race condition: Initiate concurrent requests through the malicious frontend designed to exploit unsynchronized shared data access in the daemon's multithreaded request handling, creating a race condition.
4. Cause daemon panic: The race condition causes the BuildKit daemon to reach an inconsistent state and panic, resulting in a crash and denial of service for all active and queued builds (GitHub Advisory).

• Logs: Unexpected BuildKit daemon crash logs or Go panic stack traces in the BuildKit daemon log output (e.g., buildkitd service logs showing panic: entries related to concurrent map or goroutine access).
• Process: Sudden termination or restart of the buildkitd process without a clear administrative cause; repeated daemon restarts in a short time window.
• Build System: Unexplained failures of all active build jobs simultaneously, consistent with a daemon crash rather than individual build errors.
• Frontend Activity: Use of non-standard or unrecognized external BuildKit frontends (i.e., #syntax directives pointing to untrusted or unknown images) in build configurations (GitHub Advisory).

Upgrade moby/buildkit to v0.33.1 or later, which fixes this issue along with several other security vulnerabilities (BuildKit v0.33.1 Release). As a workaround for environments that cannot immediately upgrade, avoid using external BuildKit frontends from untrusted sources; Dockerfile builds are unaffected by this vulnerability. Additionally, implement monitoring and automatic restart mechanisms for the BuildKit daemon to minimize downtime in the event of a crash (GitHub Advisory).

The vulnerability was reported by researcher 2peopledesu and disclosed by BuildKit maintainer tonistiigi via a GitHub Security Advisory on September 30, 2026 (GitHub Advisory). Red Hat tracked the issue via Bugzilla and assigned it medium priority/severity (Red Hat Bugzilla). No significant broader community or social media discussion has been observed, consistent with the moderate severity and limited exploitation potential of the vulnerability.