Beta9: three critical escapes from the sandbox that runs AI-written code

01What happened

JFrog Security Research published three critical advisories for Beta9 on November 1, 2026, all found by Natan Nehorai. Beta9 is beam-cloud's open-source runtime for serverless GPU inference, background jobs and sandboxes that run LLM-generated code. The fixes shipped ahead of the advisories, in worker 0.1.756 and gateway 0.1.776 on September 15, 2026.

02How it works

Two of the three are path handling failures. The worker's sandbox file API joined a tenant-supplied path to a mount source before cleaning parent-directory segments, so a long run of those segments reached any absolute path on the worker, and absolute symlinks inside the container resolved against the worker's root. The gateway separately built volume mount paths from a tenant-supplied identifier without checking that the workspace owned it, so parent-directory segments collapsed the path to the worker root, which was then bind-mounted read-write. The third flaw is isolation: image build steps ran under Buildah with chroot isolation only, keeping the worker pod's PID, IPC and network namespaces, so /proc/1/root exposed the worker's own writable filesystem.

03Who is affected

Self-hosted Beta9 deployments running worker versions below 0.1.756 or gateway versions below 0.1.776 are affected. JFrog says a valid workspace token and one running sandbox are enough, which is what a normal tenant already holds, and that Beta9's shipped remote-node manifests bind the worker's service account to cluster-admin.

04What to do

Upgrade both components, the gateway to 0.1.776 or later and the worker to 0.1.756 or later: JFrog notes that an old worker still mounts whatever path an old gateway sends, so a partial upgrade leaves the volume flaw open. Each advisory includes a read-only proof-of-concept check that reports whether a worker is vulnerable.

Questions people ask

Is Beta9 patched against the three sandbox escapes?

Beta9 shipped the fixes before JFrog published, in worker 0.1.756 and gateway 0.1.776 on September 15, 2026, through pull request 1897. The patched code opens sandbox paths with os.OpenRoot so parent-directory and symlink lookups stay inside the container root, validates volume ownership at the gateway, and runs Buildah build steps with private PID, IPC and network namespaces instead of chroot.

Do I need to upgrade both the Beta9 gateway and the worker?

Upgrading both components is necessary. JFrog states that the volume path traversal is fixed at the gateway, which now rejects identifiers containing a slash or parent-directory segments and volumes the workspace does not own, but an old worker still mounts whatever path an old gateway sends. A partial upgrade therefore leaves the host filesystem exposure open.

What can a Beta9 tenant reach after escaping the sandbox?

Escape gives read, write, list and delete access to the host worker's filesystem as root, including other tenants' files on the same machine. Natan Nehorai's read-only proof retrieved the worker pod's Kubernetes service account token through the sandbox file API. JFrog notes that Beta9's shipped remote-node manifests bind that service account to cluster-admin, so the token is highly privileged.

Which Beta9 operations were affected by the path flaw?

Upload, download, stat, list, find-in-files, replace-in-files and delete-file all ran through the same helper, getHostPathFromContainerPath, in the worker's container server, so any of them accepted a tenant path that escaped the container root. The build worker escape is separate and needed only one submitted image build, because Clip v2 layered builds are Beta9's default.

Sources 5 links, all fetched

1. 1research.jfrog.comContainer Escape
2. 2research.jfrog.comVolume Path Traversal
3. 3research.jfrog.comBuild Worker Escape
4. 4github.comBeta9 Fix PR 1897
5. 5github.comWorker 0.1.756 Release