CVE-2026-120308 in gateway
Summary
by MITRE • 11/01/2026
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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 11/01/2026
The vulnerability described constitutes a critical path traversal flaw within the Beta9 serverless computing platform, specifically affecting how tenant workspaces interact with persistent storage volumes during function deployment. The core technical deficiency lies in the gateway's logic for constructing host paths when attaching volumes to functions, endpoints, or task queues. Instead of validating that the provided volume identifier corresponds exclusively to a resource owned by the requesting workspace, the system blindly concatenates the shared volumes root directory, the specific workspace name, and the user-supplied volume identifier from the stub configuration. This lack of strict input validation allows an attacker with valid tenant credentials to manipulate the file path structure through the use of parent-directory traversal sequences, commonly known as dot-dot-slash or .. segments within the volume identifier string.
By injecting these directory traversal characters into the volume identifier field during deployment, a malicious actor can alter the resulting host path constructed by the gateway. These segments effectively collapse the intended isolated workspace path upward toward the worker node's filesystem root. Consequently, when the worker process executes the bind-mount operation to make this storage available within the sandboxed environment of the function or task, it mounts arbitrary paths from the underlying host machine rather than a confined volume belonging to the tenant. This behavior fundamentally breaks the isolation boundaries between different tenants and the host infrastructure, as the mount is applied with read-write permissions unless explicitly overridden by configuration flags that are often not present in default deployment scenarios.
The operational impact of this vulnerability is severe, granting an authenticated tenant unauthorized access to sensitive data residing on other tenants' workspaces or even critical system files on the worker node itself. Since the mounted path retains write capabilities, a compromised account can exfiltrate proprietary code, customer data, and configuration secrets belonging to peer organizations sharing the same physical hardware. Furthermore, the ability to write to these locations enables potential persistence mechanisms, such as planting malicious scripts or modifying shared libraries that could affect subsequent executions of legitimate workloads by other users on the node. This scenario represents a classic case of insecure direct object references combined with path traversal, leading to unauthorized data access and modification across multi-tenant boundaries.
From a classification perspective, this flaw aligns closely with CWE-22 Improper Limitation of a Pathname to a Restricted Directory, as it fails to restrict the input volume identifier from accessing directories outside its intended scope. Additionally, because the vulnerability allows an attacker to read or write files on the host system through container escape techniques via bind mounts, it maps directly to MITRE ATT&CK technique T1610 Container and Resource Discovery for reconnaissance or T1537 Transfer Data to Cloud Account if used to exfiltrate data. The attack vector is classified as remote with low complexity but requires valid authentication credentials, placing the risk profile in a high-severity category due to the breadth of potential damage including confidentiality loss and integrity compromise across multiple tenants.
Mitigation strategies implemented by Beta9 address these issues through rigorous validation at both the gateway and worker levels. The updated versions enforce strict checks on volume identifiers before any mount path is constructed, ensuring that only volumes explicitly owned by the requesting workspace are eligible for attachment. This includes retroactive enforcement against stubs saved prior to the security patch, closing loopholes where previously created configurations might have exploited the original logic flaw. By rejecting requests for non-existent or unauthorized volumes at the gateway level, the platform prevents the malformed path from ever reaching the worker node, thereby eliminating the possibility of arbitrary bind mounts and restoring proper isolation between tenants. Organizations relying on this infrastructure should immediately upgrade to the patched versions to prevent exploitation by malicious insiders or compromised accounts seeking lateral movement within the shared computing environment.