Beta9's three CVSS 9.9 flaws let a workspace token reach the shared worker as root, the CVE records say

Three boundaries, one fix, 47 days without an advisory

Three CVE records published on 1 November 2026, read between 21:34 and 21:50 GMT on Sunday 1 November 2026, describe three different boundaries in Beta9 that each failed the same way: a tenant holding only a workspace token could reach the shared worker machine's filesystem as root. One went through an image build, one through the sandbox file API, one through a volume identifier. All three carry the same CVSS 3.1 vector and the same score, 9.9, assigned by JFrog acting as the CVE Numbering Authority, not by the vendor. All three were fixed by one commit, a28bf12, released as worker 0.1.756 and gateway 0.1.776 on 15 September 2026. That is 47 days (derived) before the CVE records appeared, and the records say "No vendor security advisory was filed with the pull request."

Beta9 is Beam Cloud's open source platform. Its GitHub repository describes it as "Ultrafast serverless GPU inference, sandboxes, and background jobs", and Beam's own documentation calls it "the open-source runtime behind Beam". The people exposed are operators who run Beta9 themselves and hand workspace tokens to people or code they do not fully trust: a second team, a customer, an AI agent running generated code in a sandbox.

The derived numbers in this piece are counts and calendar arithmetic from dates the records print: three CVE records, three boundaries, one fixing commit, two components to upgrade, 8 days from the releases the researchers tested (7 September) to the fix (15 September), and 47 days from the fix to publication (1 November). The arithmetic is in the fact check file.

What the records do not establish

The records describe what a tenant could do. They do not say anyone did it. Read carefully, they leave out:

• Exploitation. None of the three records, the three GitHub advisories or the three JFrog research pages says the flaws were used against anyone. None is in CISA's Known Exploited Vulnerabilities catalogue, version 2026.10.30, read at 21:38 GMT on 1 November. A score of 9.9 measures what a flaw allows, not whether it was used.
• Beam's hosted platform. Beam says Beta9 is the runtime behind Beam Cloud. Neither Beam nor the records say whether Beam's hosted service ran the affected releases, when it was updated, or whether any customer workspace was reached. This piece does not assume either way.
• Live multi tenant testing. For CVE-2026-120308, JFrog's page says the proof "was not run against a live multi-tenant cluster." The other two proofs are described as read only.
• How many deployments. No record or page counts self hosted Beta9 installations, and this piece does not estimate one.
• Whether your cluster binds the worker to cluster-admin. The records say the shipped remote node manifests do. A cluster built another way may bind something narrower or broader.

Three doors to the same room

Each flaw sits at a different boundary, written by different code, and each ends in the same place: the worker container's filesystem, as root, on a worker pod the records describe as privileged. That filesystem holds, in the words of CVE-2026-120306, "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."

Zoom

Door one: an image build (CVE-2026-120306, worker below 0.1.756). 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 set BUILDAH_ISOLATION=chroot, and the record says no Buildah call passed an isolation flag, so a build step changed only its filesystem root. It kept the worker pod's PID, network, IPC and user namespaces, ran as uid 0 and held CAP_DAC_OVERRIDE. Because PID 1 in that process view is the worker's own entrypoint, the worker container's filesystem is visible and writable through it. The record says Clip v2 layered builds are the default, "so a tenant with a workspace token reaches this by submitting one image build."

Door two: the sandbox file API (CVE-2026-120307, worker below 0.1.756). The worker serves sandbox file operations from outside the container. A helper named getHostPathFromContainerPath turned the tenant's path into a worker path: if the path began with a mount destination, the rest was joined onto that mount's source with Go's filepath.Join, which cleans parent directory segments after the prefix check had already passed. A path matching no mount was opened in the worker's own filesystem, so an absolute symbolic link inside the sandbox was followed against the worker root. Seven operations used the helper (upload, download, stat, list, find in files, replace in files, delete file; count derived from the record's list). The record says a tenant with one running sandbox could read, write, list and delete files on the worker as root, "including files of other tenants on that machine", and that a read only proof downloaded the worker pod's Kubernetes service account token.

Door three: a volume identifier (CVE-2026-120308, gateway below 0.1.776 and worker below 0.1.756). A tenant deploying a function, endpoint or task queue can attach a volume. The gateway built the host path by joining the shared volumes root, the workspace name and the volume identifier, and nothing checked that the workspace owned the volume named. Parent directory segments in the identifier collapsed the path to the worker's root, and the worker bind mounted it into the sandbox read write unless the volume had been marked read only. JFrog's page says that on gateway 0.1.769 and worker 0.1.745 the mounted directory showed host directories rather than an empty tenant volume, and that "Other tenants' volumes stored on that host are on the same filesystem."

Stated, and not stated

A sandbox, a workspace and chroot are labels, not boundaries

Every comforting word in this story names something that was not doing the job its name suggests.

• "Sandbox". Beam's sandbox file API ran outside the sandbox, as root on the worker, and trusted a string comparison to keep the tenant inside. The boundary was a prefix check, and filepath.Join undid it.
• "Workspace". A workspace is a billing and naming unit. Volumes were filed under the workspace name, but nothing checked that the volume named belonged to that workspace. Beam's own security page adds that "All members of a workspace currently have the same permissions".
• "Isolation". BUILDAH_ISOLATION=chroot reads like a setting that isolates. The record is plain that it "only changes its filesystem root", leaving the process, network, IPC and user namespaces shared with a privileged worker.
• "Edge cases". The pull request that closed three 9.9 flaws is titled "Handle sandbox edge cases", and the release notes list it under that title. An operator reading release notes for security fixes would not have found one.

The CVSS vector encodes the same point. PR:L means a low privilege account is enough, here an ordinary workspace token. S:C, scope changed, means the damage lands outside the component that was attacked: a tenant's build or sandbox reaches the worker that hosts everyone else. What the vector does not encode is reach in the wild, or how many clusters exist. A similar pattern, where a single option rather than the microVM was the boundary that mattered, ran through this site's earlier piece The isolation that failed was a flag on the disk pool.

The cluster-admin binding the fix did not touch

CVE-2026-120307 is the record that goes furthest: the worker's Kubernetes service account token was reachable, and "In the shipped remote-node manifests that service account is bound to cluster-admin." The Kubernetes documentation describes cluster-admin, used in a ClusterRoleBinding, as giving "full control over every resource in the cluster and in all namespaces." (Kubernetes RBAC documentation)

This site read the remote node component in the repository at two points. At the commit tagged worker 0.1.745, an affected release, the file cluster-role-binding.yaml binds the beta9 service account in the default namespace to cluster-admin. At the fix commit a28bf12 the file is byte for byte the same. The fix closed the three doors; it did not narrow what the token behind them can do. At the head of the main branch on 31 October 2026 the remote node component is no longer in the repository's file list. When and why it was removed is not established here: GitHub's API rate limit stopped this site's history query, and the project has said nothing about it.

The documented route for a persistent install on AWS is the Helm chart. At the fix commit, that chart's own ClusterRole grants its service account seven verbs (get, list, watch, create, update, patch, delete) on every resource in every API group. That is not the built in cluster-admin role, and the records do not say whether worker pods run under that account. It is still broad enough that the narrowing step in the checklist below applies to chart installs as well. Both readings are this site's, from the manifests, not from the records.

What the 15 September release changed

Zoom

The commit touches ten files, adding 521 lines and removing 196, per GitHub's record of it. In plain words:

• Builds. The worker image now sets BUILDAH_ISOLATION=oci, and every Buildah RUN step, including the step that creates the WORKDIR, is given private PID, IPC and network namespaces with explicit flags. The worker image installs container networking plugins to support the private network, and RUN steps lose host network access. Tenant build arguments now go only into the build container; a code comment in the commit explains that in Buildah's own environment a tenant named argument "such as LD_PRELOAD or BUILDAH_ISOLATION would act on the worker."
• Sandbox files. File operations and workspace sync open paths through Go's os.OpenRoot, so parent directory segments and symbolic links stay inside the container root or the mount source. Operations refuse read only mounts and do not write through a symbolic link swapped in after the path was resolved. File search now scans in process instead of calling the ripgrep tool, which the worker image no longer installs.
• Volumes. A new check rejects a volume identifier that is empty, a single dot, two dots, or contains a slash, and a mount path containing a parent segment. The gateway refuses a volume the workspace does not own. Stubs saved before the check existed are checked again when they are launched, which is why JFrog's page says "both components need the upgrade."

Fixed in September, published in November

Zoom

Worker 0.1.745 and gateway 0.1.769 were published on 7 September 2026; the CVE-2026-120308 record lists them as the confirmed affected releases and says they were current at that time. Pull request 1897 was opened on 14 September and merged at 04:03 UTC on 15 September; worker 0.1.756 and gateway 0.1.776 were published within a minute. That is 8 days from the tested releases to the fix (derived). JFrog published the three CVE records between 12:49 and 12:52 UTC on 1 November, 47 days after the fix (derived), and GitHub mirrored them as unreviewed advisories at 15:30 UTC with no affected package listed. The repository's own security advisories page showed none when read. Releases have moved on since: the repository's release list shows worker 0.1.821 and gateway 0.1.840, both published on 31 October.

The records credit a researcher of JFrog Security Research as finder and JFrog Security Research as coordinator. JFrog Security Research belongs to a commercial company, JFrog Ltd, as its pages' footer shows, and published findings promote that company's work; Beam sells paid plans on the hosted platform built on Beta9, and its security page says "Workloads run in isolated containers." Both interests are worth holding in mind. Neither changes what the code and the commit show, and the fix in the repository matches the records' description of it.

A 47 day gap between a quiet fix and the CVE is common in open source and is not itself a fault: it gives operators time to upgrade before the details are public. It only works if operators upgrade without being told why. Beta9 releases frequently, so anyone tracking releases would have taken the fix; anyone waiting for a security notice had nothing to wait for until 1 November.

What to do, in order

Technical details

The blocks below are copied from the primary sources as printed, each named in its caption. They are for finding and confirming exposure. JFrog's pages also publish proof scripts; none is reproduced here, and no path payload is printed.

The three record descriptions. These are the CNA's own words, the most complete statement of each flaw. Read them to decide which of your clusters match the preconditions.

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.

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 upload mount at /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 those segments names any absolute path on the worker. A path that matches no mount is joined onto the container root and opened in the worker's own filesystem, so an absolute symbolic link such as /var/run pointing at /run is followed against the worker root. Upload, download, stat, list, find-in-files, replace-in-files, and delete-file all call this helper. A tenant with a workspace token and one running sandbox can read, write, list, and delete files on the hosting worker as root, including files of other tenants on that machine. A read-only proof downloaded the worker pod's Kubernetes service account token through the file API for a path that did not exist inside the sandbox. In the shipped remote-node manifests that service account is bound to cluster-admin. Fixed in worker 0.1.756: sandbox file operations and workspace sync open paths with os.OpenRoot, so parent-directory and symlink lookups stay inside the container root or the mount 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.

Scores, weaknesses and affected ranges. All three share one CVSS 3.1 vector. The affected ranges are what a version inventory should be compared against; note that CVE-2026-120308 lists both components.

CVE-2026-120306  CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H  9.9 CRITICAL  CWE-653, CWE-269
  Beta9 worker: affected from 0, lessThan 0.1.756 (semver)
CVE-2026-120307  CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H  9.9 CRITICAL  CWE-22, CWE-23, CWE-59
  Beta9 worker: affected from 0, lessThan 0.1.756 (semver)
CVE-2026-120308  CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H  9.9 CRITICAL  CWE-22, CWE-668
  Beta9 gateway: affected from 0, lessThan 0.1.776 (semver)
  Beta9 worker: affected from 0, lessThan 0.1.756 (semver)

The build isolation setting, before and after. These lines sit in the worker image's Dockerfile. If a running worker image still carries the first form, it predates the fix.

ENV _BUILDAH_STARTED_IN_USERNS="" \
    BUILDAH_ISOLATION=chroot

ENV _BUILDAH_STARTED_IN_USERNS="" \
    BUILDAH_ISOLATION=oci

The flags the fix adds to every build step. This function, added by the fix, is what turns a chroot into a container with its own process, IPC and network namespaces. It is defensive code, shown so a reviewer can recognise it in a fork.

// buildahIsolationArgs give a RUN step its own PID, IPC and network
// namespaces. Its commands are tenant code and the worker is privileged, so
// nothing of the worker's may be reachable from them. Explicit flags win over
// BUILDAH_ISOLATION and containers.conf.
func buildahIsolationArgs() []string {
	return []string{"--isolation=oci", "--pid=private", "--ipc=private", "--network=private"}
}

The volume check. This is the rule a stored stub must now pass. A defender can apply the same rule when searching stored stub configurations for earlier attempts (checklist item seven).

// ValidateVolume rejects ids and mount paths that would carry a bind mount
// source, or the symlink to it, outside the workspace's own directories.
// Bucket mounts have no volume record, so their id may be empty.
func ValidateVolume(v *pb.Volume) error {
	if v == nil {
		return errors.New("volume is required")
	}
	if (v.Id == "" && v.Config == nil) || v.Id == "." || v.Id == ".." || strings.Contains(v.Id, "/") {
		return fmt.Errorf("invalid volume id %q", v.Id)
	}
	if slices.Contains(strings.Split(v.MountPath, "/"), "..") {
		return fmt.Errorf("invalid volume mount path %q", v.MountPath)
	}
	return nil
}

The binding the records name. This is the remote node component's ClusterRoleBinding. It is identical at worker 0.1.745 and at the fix commit. If your cluster has an equivalent binding for the account your worker pods use, that account's token is a cluster administrator credential.

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: beta9-admin-binding
  namespace: default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: beta9
  namespace: default

The Helm chart's role rule. For chart installs, this is the rule the chart's ClusterRole grants its service account at the fix commit. Whether worker pods use that account is not stated in the records; check your own pod specs.

rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

The exploitation check. The catalogue version and the result, as read. Recheck before acting on the absence.

catalogVersion: 2026.10.30
dateReleased: 2026-10-30T17:02:45.3665Z
count: 1766
CVE-2026-120306, CVE-2026-120307, CVE-2026-120308: not listed

The question that exposes the gap

Three separate boundaries failed, each by trusting a tenant's string, and behind all three sat a token that the project's own remote node manifests made a cluster administrator. The fix closed the doors in September. It left the token's power where it was, and it shipped under the title "Handle sandbox edge cases" with no advisory. Projects that ship example manifests carry the same risk this site found in LMCache's Kubernetes example: operators copy them.

So the question for any team running Beta9, or any platform that runs other people's code next to its own: if a tenant reached your worker's root tomorrow, what could the token on that worker do to the rest of your cluster, and who decided it should be able to?

Key facts