CVE-2026-120306 in Beta9 worker
Summary
by MITRE • 11/01/2026
Beta9 turns each shell command in a tenant image definition into a Dockerfile RUN line and executes it with Buildah on the build worker. The worker image sets BUILDAH_ISOLATION=chroot, and no buildah invocation passes --isolation, so the step only changes its filesystem root. It keeps the worker pod's PID, network, IPC, and user namespaces, runs as uid 0, and holds CAP_DAC_OVERRIDE. PID 1 in that procfs is the worker entrypoint, so /proc/1/root is the worker container's filesystem and is writable. That filesystem contains the runc, buildah, and runsc binaries the worker uses to start tenant containers, the worker's Kubernetes service account token, and the host directories mounted into the pod. Worker pods are privileged. Clip v2 layered builds are the default, so a tenant with a workspace token reaches this by submitting one image build. The read-only proof confirmed the shared namespaces, CAP_DAC_OVERRIDE, and that the worker's runc binary is visible at /proc/1/root. Fixed in worker 0.1.756: Buildah RUN steps, including the WORKDIR mkdir, use OCI isolation with private PID, IPC, and network namespaces, and tenant ARG values are passed only into the build container.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 11/01/2026
The vulnerability described involves a critical privilege escalation flaw within Beta9's image building infrastructure, specifically affecting how shell commands in tenant-defined images are executed on build workers. The core technical issue stems from the configuration of Buildah when processing these commands. Instead of utilizing isolated environments for each command execution, the system defaults to using chroot isolation by setting the BUILDAH_ISOLATION environment variable to chroot and omitting any explicit --isolation flags during invocation. This configuration results in a severe lack of namespace separation. While the filesystem root is changed via chroot, the process retains access to the worker pod's original PID, network, IPC, and user namespaces. Consequently, the build step operates with full privileges as uid 0 and holds the CAP_DAC_OVERRIDE capability, which allows it to bypass file permission checks on any file within those shared namespaces.
The operational impact of this flaw is profound because it grants tenant workloads unrestricted access to the underlying worker node's environment. Since PID 1 in the procfs namespace corresponds to the worker entrypoint process, the path /proc/1/root points directly to the writable filesystem of the worker container itself. This means that a malicious or compromised tenant image can read and modify critical system binaries located within this shared root directory, including runc, buildah, and runsc, which are essential for starting subsequent tenant containers. Furthermore, the attacker gains access to sensitive artifacts such as the Kubernetes service account token stored on the worker node and any host directories that have been mounted into the pod. This effectively breaks the multi-tenant isolation boundary, allowing a single image submission to compromise not just the build environment but potentially other tenants sharing the same worker node or even the underlying infrastructure if container escape techniques are employed using the compromised binaries.
This vulnerability is particularly dangerous because Clip v2 layered builds are set as the default configuration, meaning that any tenant possessing a workspace token can trigger this code path simply by submitting one image build request. The proof of concept confirmed these conditions by demonstrating shared namespaces and the visibility of the worker's runc binary at /proc/1/root, validating that the isolation mechanisms were entirely ineffective against privileged processes with CAP_DAC_OVERRIDE. This scenario aligns closely with CWE-250, which describes execution with unnecessary privileges, and CWE-78, improper neutralization of special elements used in an OS command, as well as ATT&CK techniques related to container escape and privilege escalation within Kubernetes environments. The lack of namespace isolation represents a fundamental failure in the principle of least privilege for build agents.
The issue was resolved in worker version 0.1.756 by fundamentally altering how Buildah RUN steps are executed. The fix ensures that these steps, including directory creation via WORKDIR, utilize OCI isolation rather than chroot. This change enforces private PID, IPC, and network namespaces for each build step, effectively isolating the tenant's processes from the worker node's environment. Additionally, the mitigation includes restricting the scope of tenant ARG values so they are passed only into the isolated build container, preventing them from influencing the host or shared system context. This remediation restores proper multi-tenant isolation and prevents unauthorized access to sensitive worker resources such as service account tokens and critical binaries. Organizations relying on this infrastructure should ensure their workers are updated to version 0.1.756 or later to mitigate these risks and maintain strict separation between tenant build processes and the underlying node environment.