CVE-2026-121520 in BuildKit
Summary
by MITRE • 11/04/2026
In BuildKit versions prior to v0.34.1, a malicious client with access to the BuildKit control APIs can submit a build request that sets an extended attribute on a file outside the BuildKit state directory. Extended attributes in the trusted. or security. namespaces may also be set, potentially giving a program on the host elevated privileges. This issue affects build services that accept build requests from untrusted users. The issue is fixed in v0.34.1.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 11/04/2026
The vulnerability identified in BuildKit versions prior to v0.34.1 represents a critical security flaw within container image building infrastructure, specifically targeting the integrity of file system operations during the build process. BuildKit serves as the core engine for constructing OCI-compliant images and is frequently deployed in shared environments where multiple users or tenants submit build requests through control APIs. The fundamental issue arises from an insufficient validation mechanism regarding file paths when applying extended attributes to files created during a build operation. In standard Linux systems, extended attributes allow metadata to be attached to files beyond the standard permissions model, often used for security labels such as SELinux contexts or AppArmor profiles. When BuildKit processes these operations without strict path confinement, it allows a malicious client to manipulate file system states outside of the designated state directory where build artifacts are supposed to remain isolated.
This lack of proper sandboxing enables an attacker with access to the BuildKit control APIs to execute arbitrary extended attribute assignments on files located in sensitive host directories. By targeting files within trusted or security namespaces, such as those managed by SELinux or other mandatory access control systems, a malicious actor can potentially alter the security context of critical system binaries or configuration files. This manipulation may effectively bypass existing isolation boundaries, allowing code executed during subsequent operations to gain elevated privileges on the underlying host operating system. The severity is amplified in multi-tenant build services where untrusted users are permitted to submit builds, as it transforms a routine image construction task into a potential privilege escalation vector that compromises the entire infrastructure hosting the service.
From an industry standards perspective, this vulnerability aligns with CWE-284 Improper Access Control and CWE-732 Incorrect Permission Assignment for Critical Resource. The failure to restrict file system operations to a specific sandboxed directory constitutes a classic path traversal or escape scenario, violating the principle of least privilege by granting write access to resources outside the intended scope. Furthermore, this behavior maps directly to MITRE ATT&CK technique T1059 Command and Scripting Interpreter via indirect command execution, as well as T1611 Escape to Host, which describes scenarios where containerized workloads break out into the host environment due to misconfigurations or vulnerabilities in orchestration tools. The ability to modify security labels effectively undermines the integrity of mandatory access control policies that rely on accurate metadata assignment for enforcing isolation between processes and files.
The operational impact extends beyond immediate privilege escalation, potentially leading to persistent compromise if an attacker modifies system binaries or critical configuration files with malicious extended attributes. These changes may remain undetected until a subsequent build or service restart triggers the altered security context, at which point the compromised file could execute with unintended permissions. This creates a stealthy persistence mechanism that is difficult to audit using standard permission checks alone, as traditional tools often ignore extended attribute modifications unless specifically configured to monitor them. The risk is particularly acute in continuous integration and deployment pipelines where build artifacts are automatically promoted across environments based on assumed integrity guarantees provided by the container runtime.
Mitigation strategies must prioritize immediate version upgrades for all instances of BuildKit running untrusted workloads. Organizations should upgrade to v0.34.1 or later, which implements strict path validation to ensure that extended attribute operations are confined exclusively within the designated state directory. In addition to patching, infrastructure teams should enforce network-level access controls on BuildKit APIs, ensuring that only authorized service accounts can submit build requests rather than exposing these endpoints directly to end-users. Implementing robust input validation and sanitization for all file path parameters passed to system calls is essential to prevent similar logic flaws in other components of the container ecosystem. Regular auditing of extended attribute usage across critical host directories can also help detect any unauthorized modifications that may have occurred prior to remediation, ensuring comprehensive recovery from potential exploitation attempts.