CVE-2026-121542 in Buildx
Summary
by MITRE • 11/04/2026
In Docker Buildx versions v0.19.0 through v0.38.0, an untrusted Bake definition may expose files accessible to the Buildx client without the expected fs.read approval. Under certain conditions, paths under the same parent directory as the current working directory whose names use the working directory's basename as a prefix can skip the filesystem entitlement check. Exploitation requires specific matching filenames next to the current project directory. Users who run untrusted Bake definitions may be affected. The issue is fixed in v0.38.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 within Docker Buildx versions ranging from v0.19.0 through v0.38.0 represents a critical failure in access control mechanisms governing file system operations during the image building process. This flaw specifically impacts users who execute untrusted Bake definitions, which are declarative build configuration files used to orchestrate complex multi-stage builds and shared configurations within the Docker ecosystem. The core technical deficiency lies in how Buildx validates filesystem entitlements when resolving paths for read operations. Under specific conditions involving path resolution logic, the system fails to correctly enforce security boundaries, allowing access to sensitive host files that should remain isolated from the build context or require explicit user approval via fs.read permissions.
The mechanism of exploitation relies on a subtle error in how relative paths are normalized and validated against allowed directories. When an untrusted Bake definition specifies file operations, Buildx is designed to restrict access primarily to the current working directory and its subdirectories unless broader filesystem entitlements are explicitly granted by the user. However, due to this vulnerability, if certain files exist on the host system in a parent directory adjacent to the project root, they can be accessed without triggering the expected security checks. Specifically, paths located under the same parent directory as the current working directory become accessible if their filenames utilize the basename of the working directory as a prefix. This condition allows an attacker or malicious build script to bypass isolation boundaries and read arbitrary files from the host environment that are not part of the intended project structure but share this specific naming pattern with the active workspace.
From a security classification perspective, this issue aligns closely with CWE-284 Improper Access Control, as it involves unauthorized access to resources due to flawed permission checks. It also relates to CWE-732 Incorrect Permission Assignment for Critical Resource, where the system fails to assign appropriate restrictions to files that should be protected from untrusted build contexts. In terms of adversary tactics, this vulnerability facilitates techniques associated with ATT&CK T1083 File and Directory Discovery, as it enables an attacker to enumerate and read sensitive host files during a containerized build process. The operational impact is significant for developers who incorporate third-party or community-provided Bake definitions into their CI/CD pipelines without rigorous vetting. Successful exploitation could lead to the exfiltration of source code secrets, configuration credentials, private keys, or other proprietary data stored on the developer's machine outside the project directory but matching the specific naming criteria described above.
The severity of this vulnerability is compounded by its potential for stealthy exploitation in automated environments where users may not closely monitor every file access event during a build. If an untrusted Bake definition is executed as part of a continuous integration workflow, it could silently leak sensitive information to external parties controlled by the maintainer of that definition. This poses a direct risk to supply chain security and intellectual property protection within software development organizations relying on Docker Buildx for their build infrastructure.
To mitigate this risk, immediate action must be taken to upgrade Docker Buildx to version v0.38.1 or later, where the path validation logic has been corrected to properly enforce filesystem entitlements regardless of filename prefixes or parent directory relationships. Organizations should also implement strict policies regarding the use of untrusted Bake definitions in production build pipelines. This includes validating all external configuration files against known good baselines and restricting Buildx execution environments to minimize potential blast radius. Additionally, developers should adopt a principle of least privilege by ensuring that Docker daemon configurations do not grant unnecessary broad filesystem access rights unless explicitly required for specific trusted projects. Regular auditing of CI/CD artifacts and build scripts can further reduce the likelihood of encountering such vulnerabilities in future deployments.