BuildKit CVE-2026-93326

Exploitation requires the attacker to control or influence a BuildKit build definition (PR:L) and to craft a Git-source build step in a specific way (AT:P reflects this crafting requirement), so it applies to environments where untrusted or semi-trusted parties can submit builds to a shared BuildKit instance. The bypass is scoped to URL/remote-identity policy checks only: per the vendor, policies validating commit SHA, commit data, or signatures continue to apply correctly, which is the primary limiting factor. It does not enable unauthenticated access, and no user interaction (UI:N) is needed once build-submission privilege is held.

This is a moderate, integrity-focused policy-bypass issue rather than a high-urgency emergency. The CVSS 4.0 score of 6.0 (AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:H/VA:N) shows a network vector but with an explicit Attack Requirement (AT:P) and required privileges (PR:L), meaning the attacker must already be able to submit a build definition to a BuildKit instance - this is a trusted-builder/CI threat model, not drive-by remote code execution. The dominant impact is integrity (VI:H): a crafted Git-source build step can make a clone appear to originate from a different remote URL, defeating URL-based policy validation. No EPSS score was provided in the input and the vulnerability is not on the CISA KEV list, so there is no evidence of active exploitation; no public PoC is referenced either. Signals are internally consistent - a privileged/authenticated-position bug with real integrity impact but a meaningful precondition - so this is a genuine supply-chain hardening priority for organizations enforcing source-URL build policies, but not a widespread-exploitation fire drill. Importantly, per the description, stricter policies keyed on commit SHA, commit data, or signatures are NOT bypassed, which materially lowers real-world risk for mature pipelines.

An actor who can submit build definitions to a shared BuildKit/CI build service crafts a Git-source build step so that an audit/admission policy sees an approved remote URL while BuildKit actually clones from an attacker-chosen repository. This lets malicious source slip past URL allow-list policies and into trusted build outputs. No public exploit code is referenced, and the attack requires the ability to influence a build definition (PR:L) plus specific crafting conditions (AT:P).