CVE-2026-120307 in Beta9 worker
Summary
by MITRE • 11/01/2026
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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 11/01/2026
The vulnerability identified involves a critical path traversal flaw within the Beta9 worker's sandbox file API implementation, specifically in the getHostPathFromContainerPath function which translates tenant-specified container paths into host-side filesystem locations. This architectural component is responsible for bridging operations from inside an isolated container environment to the underlying worker node's physical or virtualized storage infrastructure. The core technical flaw stems from insufficient validation of path segments during this translation process, allowing a malicious actor to escape the intended sandbox boundaries and access arbitrary files on the host system with root privileges.
The mechanism of exploitation relies on manipulating parent-directory traversal sequences within file paths provided by the tenant. When a request is made for a container path that begins with a designated mount destination, such as the default upload mount at /tmp/.beta9, the system attempts to map this to a corresponding source directory on the worker host. Although the implementation includes a check to ensure the resolved path starts with the expected mount prefix and performs some cleaning of parent-directory segments after this initial validation, it fails to adequately sanitize sequences that can bypass these checks through length or specific structural manipulation. By providing a sufficiently long sequence of parent-directory references, an attacker can effectively neutralize the prefix constraint, causing the filepath.Join operation to resolve to any absolute path on the worker node rather than remaining confined within the intended mount point.
Furthermore, for paths that do not match any configured mount destination, the system defaults to joining them onto the container root and opening them against the worker's own filesystem context. This behavior is particularly dangerous because it allows symbolic links to be followed outside of the sandbox environment. For instance, a path referencing an absolute symbolic link like /var/run, which typically points to /run on many Linux distributions, will cause the system to follow that symlink relative to the worker root rather than the container root. Since file operations such as upload, download, stat, list, find-in-files, replace-in-files, and delete-file all invoke this vulnerable helper function, an attacker with a valid workspace token and access to one running sandbox can perform comprehensive read, write, list, and delete actions on files located anywhere on the hosting worker.
The operational impact of this vulnerability is severe, as it grants unauthorized root-level access to the host machine for any tenant possessing a workspace token and active sandbox instance. This effectively breaks all isolation guarantees provided by the containerization layer, allowing attackers to exfiltrate sensitive data belonging to other tenants or compromise the integrity of the hosting infrastructure. A proof-of-concept demonstration confirmed this severity by successfully downloading the Kubernetes service account token from the worker pod through the file API using a path that did not exist within the sandbox environment itself. The compromised service account was bound to cluster-admin privileges in the shipped remote-node manifests, meaning successful exploitation could lead to full control over the entire Kubernetes cluster, enabling further lateral movement and persistent access.
This vulnerability aligns with CWE-22: Improper Limitation of a Pathname to a Restricted Directory, as it allows an actor to traverse outside restricted directories via path manipulation. It also maps to MITRE ATT&CK techniques related to Lateral Movement and Data Exfiltration, specifically leveraging compromised credentials or tokens to access sensitive system resources such as service account keys. The flaw represents a classic example of how improper handling of file paths in security-critical APIs can lead to complete environment compromise when combined with high-privilege bindings like cluster-admin roles.
The issue has been addressed in worker version 0.1.756 through the implementation of os.OpenRoot for sandbox file operations and workspace synchronization tasks. This mitigation ensures that all path lookups, including those involving parent-directory traversal or symbolic link resolution, are strictly confined within the container root directory or the designated mount source directories. By anchoring filesystem access to a specific base directory using OS-level restrictions rather than relying solely on application logic for validation, the system prevents any possibility of escaping the sandbox environment through path manipulation techniques. Organizations running affected versions should immediately upgrade their worker nodes to version 0.1.756 or later and rotate all workspace tokens and Kubernetes service account credentials that may have been exposed during potential exploitation windows.