Three Ways Beta9 Lets a Tenant Escape Its Sandbox

Three new vulnerabilities in Beam Cloud’s Beta9, the open-source engine behind Beam’s serverless GPU platform, let a tenant escape its own sandbox. The escape reaches the host worker and other tenants sharing it, not just the tenant’s own container. Operators update the worker service to 0.1.756, and the gateway service to 0.1.776, now.

Who Runs Beta9, and Why the Wall Matters

Beta9 is the open-source engine behind Beam, used for serverless GPU inference, isolated code-execution sandboxes and background task queues. A company can self-host it on its own AWS, GCP or bare-metal infrastructure, or run the same engine as Beam’s managed cloud service. All three flaws sit in the wall the product depends on: the line between one tenant’s workload and the host, or another tenant’s workload on the same worker.

CVE-2026-120306, CVE-2026-120307 and CVE-2026-120308 all score CVSS 3.1 9.9 Critical, vector AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. There is no CVSS 4.0 score in the record or NVD. All three are credited to JFrog Security Research via its CNA, listed on each record as reefs@jfrog.com. None is in CISA’s Known Exploited Vulnerabilities catalog as of 1 November 2026.

A Build Step Reaches the Worker’s Own Files (CVE-2026-120306)

Beta9 turns each shell command in a tenant’s image definition into a Dockerfile RUN line and runs it with Buildah on the build worker. The worker image sets BUILDAH_ISOLATION=chroot, so each RUN step only changes its filesystem root.

The step still keeps the worker pod’s PID, network, IPC and user namespaces, runs as uid 0, and holds CAP_DAC_OVERRIDE. From inside it, /proc/1/root resolves to the worker’s own filesystem and is writable. That reaches binaries such as runc and buildah, plus the pod’s Kubernetes service account token, exactly what lets a bug escalate privileges on the host.

A File API Call Reaches Any Path on the Host (CVE-2026-120307)

The worker’s sandbox file API turns a tenant’s container path into a worker path through getHostPathFromContainerPath. Parent-directory segments placed before a mount’s path get quietly cleaned away during the join, the same bug class as a recent WinRAR path traversal flaw. A followed symbolic link opens a second route around the same check.

Upload, download, stat, list, find-in-files, replace-in-files and delete-file all call that function. A tenant with only a workspace token and a running sandbox can read, write, list and delete files on the worker host as root, including other tenants’ files on it. One proof read the worker pod’s Kubernetes token this way, for a file that does not exist inside the sandbox. Beta9’s own shipped manifests bind that token to the cluster-admin role.

A Volume Mount Reaches the Worker’s Filesystem Root (CVE-2026-120308)

A tenant can attach a volume when it deploys a function, endpoint or task queue. The gateway joins the shared volumes root, the workspace name and a volume identifier the tenant supplies, with nothing checking that the identifier names a volume the workspace actually owns.

Parent-directory segments in that identifier collapse the path down to the worker’s own filesystem root, which the worker then bind-mounts into the sandbox, read-write unless the volume was marked read-only. The reporting researcher confirmed this against gateway 0.1.769 and worker 0.1.745; the flaw starts in the gateway, so the worker upgrade alone does not close it.

All three reach the same place a VMware ESXi sandbox escape once did on a different platform. The Kubernetes token two of them expose is also a shortcut to what MITRE’s T1068 technique describes.

Fixed Versions

Beam Cloud fixed all three in one pull request on GitHub, merged as commit a28bf12. The table below lists both upgrades.

What to Do Now