CVE-2026-120306
CriticalCVSS 9.9Summary
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, keeping the worker pod's PID, network, IPC, and user namespaces, running as uid 0 with 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, containing the runc, buildah, and runsc binaries, the worker's Kubernetes service account token, and host directories mounted into the pod. Worker pods are privileged, and Clip v2 layered builds are the default, so a tenant with a workspace token reaches this by submitting one image build.
Risk Assessment
A tenant can access the worker's filesystem and execute arbitrary commands with root privileges, including obtaining the Kubernetes service account token and potentially taking over the cluster. Affects Beta9 workers before 0.1.756.
Recommendation
Update the Beta9 worker to version 0.1.756 or later, which uses OCI isolation with private PID, IPC, and network namespaces for Buildah RUN steps and passes tenant ARG values only into the build container.
Other vulnerabilities in Beta9
See all- CVE-2026-120308Critical
In Beta9, a tenant can attach a volume when deploying a function, endpoint, or task queue. The gateway builds the host path by joining the shared volumes root, the workspace name, and the volume identifier from the stub configuration, without checking that the identifier names a volume owned by that workspace. Parent-directory segments in the identifier collapse the joined path to the worker's filesystem root, which is bind-mounted read-write into the sandbox, allowing read and write access to the worker's files, including other tenants' volumes.
- CVE-2026-120307Critical
The Beta9 worker serves the sandbox file API from outside the container. getHostPathFromContainerPath turns the tenant's container path into a worker path; if the unresolved path starts with a mount destination (including the default /tmp/.beta9), the remainder is joined onto that mount's source with filepath.Join, which cleans parent-directory segments after the prefix check. A long enough run of such segments names any absolute path on the worker, and a path matching no mount is opened in the worker's filesystem, following absolute symbolic links. A tenant with a workspace token and a running sandbox can read, write, list, and delete files on the worker as root, including other tenants' files.
Original NVD description (English source)
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.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS