BuildKit CVE-2026-15788

The target BuildKit daemon must be explicitly configured to use Windows Container on Windows (WCOW) workers - this is not the default BuildKit deployment mode and requires deliberate Windows-specific setup. The attacking build must use the --mount=type=cache,source=<name> directive in a RUN instruction so that BuildKit accesses the cache root during build execution. The attacker must have the ability to author and submit builds to the target daemon (PR:N in the CVSS 4.0 vector confirms no build-authoring privilege is required beyond access to submit). A human operator or automated trigger must execute the build (UI:A), meaning the attack is not fire-and-forget against a passive target. Exploitation is limited to files reachable by the BuildKit daemon process's Windows service account - secrets outside that process's read permissions are not exposed. Linux-based and macOS-based BuildKit workers are entirely unaffected, and deployments where all build authors are trusted parties face no realistic risk.

The CVSS 4.0 base score of 5.6 (Medium) reflects a real but constrained attack surface. The AV:L (local) metric indicates the attacker must have some form of access to submit builds to the target daemon - typically via the daemon socket - rather than exploiting a remotely reachable network service. AT:P confirms specific prerequisites: the daemon must be configured for WCOW workers, which is a non-default Windows-specific deployment mode. UI:A (active user interaction) requires someone to execute or accept the malicious build. The VC:H (high confidentiality impact on vulnerable component) is significant: if exploited, an attacker can exfiltrate any host file the daemon process can read, which in practice may include credentials, secrets, private keys, or configuration files mounted into the CI/CD environment. There is no integrity or availability impact. The absence of a KEV listing and no identified public exploit code further constrains real-world urgency, but the risk is materially elevated in shared build infrastructure scenarios - SaaS CI/CD platforms, self-hosted runners with untrusted contributor access, or build farms where multiple tenants submit Dockerfiles to a common WCOW daemon. EPSS data was not provided in the input; risk classification relies on CVSS vector and contextual analysis.

An attacker with the ability to submit Dockerfiles to a shared WCOW BuildKit daemon - for example, through a pull request to a repository whose CI/CD runs BuildKit on Windows - crafts a build that uses a cache mount and pre-populates the cache root with an NTFS directory junction pointing to a sensitive host path such as a secrets directory or user profile. When an operator or automated pipeline runs the build, BuildKit follows the junction without detection, and the build stage reads and potentially exfiltrates files from the host. No public proof-of-concept has been identified, but the technique is well-understood given the long history of Windows junction abuse in similar filesystem isolation contexts.