Beta9 worker: tenant image build steps run with chroot isolation only and escape to the privileged worker pod

Impact

Beta9 (beam-cloud) is the serverless GPU runtime that hosts tenant containers on worker nodes, and it turns each shell command in a tenant image definition into a Buildah RUN step. With BUILDAH_ISOLATION=chroot and no --isolation flag anywhere, that step changes only 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 the shared procfs is the worker entrypoint, so /proc/1/root is the worker container's own writable filesystem - containing the runc, buildah and runsc binaries used to launch every other tenant's container, the worker's Kubernetes service account token, and the host directories mounted into the pod. Worker pods are privileged, and Clip v2 layered builds are the default, so one image build from any tenant holding a workspace token gets code execution over the shared worker and a path to tamper with the runtimes other tenants are about to be started under. The researcher's read-only proof confirmed the shared namespaces, the capability and the visible runc binary.

Who can reach it

Any tenant holding a Beta9 workspace token who can submit one image build - the default Clip v2 layered build path reaches it. Authenticated as an ordinary tenant; no node access and no special privileges needed.

What to do

Upgrade the Beta9 worker to 0.1.756, where Buildah RUN steps (including the WORKDIR mkdir) use OCI isolation with private PID, IPC and network namespaces and tenant ARG values are confined to the build container. Rolling the worker image means restarting worker pods, which kills in-flight tenant builds and sandboxes; no host reboot or firmware work is needed. Because the flaw lets a tenant write to binaries and tokens on the worker, treat any worker that ran untrusted builds on an older version as compromised: replace the pod rather than restart it, and rotate the worker service account token.

References

Related entries

• Beta9 worker: sandbox file API path traversal gives a tenant root read/write across the whole workerCVE-2026-120307 · Beta9 worker (sandbox file API, getHostPathFromContainerPath)Critical
• Rancher Fleet: incomplete ServiceAccount impersonation lets a tenant read secrets on every targeted clusterCVE-2026-41050 · Rancher Fleet Helm deployer (ServiceAccount impersonation)Critical
• Rancher Fleet: missing valuesFrom validation lets one tenant read another tenant's Fleet credentialsCVE-2026-44935 · SUSE Rancher Fleet (Helm Deployer valuesFrom)Critical
• Oracle TimesTen In-Memory Database: Kubernetes Operator flaw gives a low-privileged user full takeoverCVE-2026-60402 · Oracle TimesTen In-Memory Database (Kubernetes Operator)Critical
• LXD: newline injection in NVIDIA instance config yields code execution as the LXD daemonCVE-2026-63298 · Canonical LXD (NVIDIA instance configuration: nvidia.driver.capabilities, nvidia.require.*)Critical
• RHACM HelmRelease controller: tenant-supplied charts render with the controller's cluster-wide ServiceAccountCVE-2026-67567 · Red Hat Advanced Cluster Management multicloud-operators-subscription (HelmRelease controller)Critical