Beta9 worker: sandbox file API path traversal gives a tenant root read/write across the whole worker

Impact

The Beta9 worker serves the sandbox file API from outside the container and maps tenant paths to worker paths in getHostPathFromContainerPath. The prefix check runs against the unresolved path, then filepath.Join cleans the parent-directory segments afterwards, so a long enough run of ../ after a mount destination such as the default upload mount /tmp/.beta9 names any absolute path on the worker; a path matching no mount is joined onto the container root and opened in the worker's own filesystem, where an absolute symlink is followed. Upload, download, stat, list, find-in-files, replace-in-files and delete-file all go through that helper, so one tenant with a workspace token and a running sandbox reads, writes, lists and deletes files on the shared worker as root - including other tenants' files on the same machine. The researcher's read-only proof pulled the worker pod's Kubernetes service account token this way, and in the shipped remote-node manifests that account is bound to cluster-admin, so this is a straight line from one tenant sandbox to control of the GPU cluster.

Who can reach it

Any tenant with a Beta9 workspace token and one running sandbox, over the network through the normal sandbox file API. Authenticated as an ordinary tenant only.

What to do

Upgrade the Beta9 worker to 0.1.756, where sandbox file operations and workspace sync use os.OpenRoot so parent-directory and symlink resolution cannot leave the container root or the mount source. Rolling worker pods interrupts running sandboxes but needs no host reboot. Given that the proof-of-concept retrieves a cluster-admin-bound service account token, rotate the worker service account credentials and review the RBAC binding in the remote-node manifests as part of the same change.

References

Related entries

• 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
• Red Hat ACM: unvalidated ocm-managed-cluster annotation lets a hub tenant target any spoke clusterCVE-2026-72526 · Red Hat ACM multicloud-integrations (Argo CD Application propagation controller)Critical