CVE-2026-120308
CriticalCVSS 9.9Summary
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.
Risk Assessment
A tenant with a workspace token can access the worker's files and other tenants' volumes on the same machine, leading to confidentiality and integrity breaches. Confirmed against gateway 0.1.769 and worker 0.1.745.
Recommendation
Update the gateway to version 0.1.776 or later and the worker to 0.1.756 or later, which validate volume identifiers and mount paths before building a mount.
Other vulnerabilities in Beta9
See all- 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.
- CVE-2026-120306Critical
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.
Original NVD description (English source)
A Beta9 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. Nothing checks that the identifier names a volume that workspace owns. Parent-directory segments in the identifier collapse the joined path to the worker's filesystem root, and the worker bind-mounts that path into the sandbox read-write unless the volume was explicitly marked read-only. A tenant with a workspace token can therefore read and write the worker's files, including other tenants' volumes stored on that machine. Confirmed against gateway 0.1.769 and worker 0.1.745. Fixed in gateway 0.1.776 and worker 0.1.756: volume identifiers and mount paths are validated before a mount is built, including for stubs saved before the check existed, and the gateway rejects a volume that does not exist or is not owned by the workspace.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS