Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate with workspace token
-
DeliveryStart sandbox, invoke file API
-
ExploitSubmit container path with traversal/symlink
-
ExecutionResolve to cluster-admin SA token on worker root
-
PersistDownload token, assume cluster-admin
-
ImpactRead/write/delete other tenants' files as root
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V5 - File Handling Path canonicalization, traversal prevention
MITRE ATT&CK
2 techniques across 2 tactics: Discovery, Collection The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires a valid workspace token and at least one running sandbox on the target worker (PR:L); it is remotely reachable because the worker serves the sandbox file API from outside the container (AV:N). No special non-default configuration is needed - the default upload mount at /tmp/.beta9 is itself an exploitable prefix, and a path matching no mount is joined onto the container root where an absolute symlink (e.g. /var/run → /run) is followed against the worker filesystem; all of upload, download, stat, list, find-in-files, replace-in-files, and delete-file reach the vulnerable getHostPathFromContainerPath helper. Exploitation is limited to worker versions before 0.1.756 (fixed there via os.OpenRoot). The impact is maximized on the shipped remote-node manifests, where the worker pod's service account is bound to cluster-admin, turning host file read into full cluster compromise; UI:N means no victim interaction is required. |
| Impact | This is a genuine top-priority issue, not an inflated high-CVSS score. The vendor-supplied CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, 9.9) is internally consistent with the described mechanism: network-reachable sandbox file API, low attack complexity, only a low-privilege workspace token plus one running sandbox required (PR:L), no user interaction, and a scope change from the tenant container to the worker host with full confidentiality/integrity/availability impact. The vuln.today decision label is act_now and a patch is available, which together argue for immediate remediation. The reporter (JFrog) describes a working read-only proof that pulled the worker pod's Kubernetes service account token - which the shipped remote-node manifests bind to cluster-admin - so the realistic impact is full cluster compromise and cross-tenant file access as root. No EPSS score and no CISA KEV status are present in the input, so exploitation probability and confirmed in-the-wild use cannot be quantified from this data; absence of KEV means active exploitation is NOT confirmed. The references list contains no standalone exploit/PoC link, only the vendor repo, patch PR, patch commit, and release tag; the detailed proof is narrated in the description by the reporter rather than supplied as public exploit code. Net: severity and exploitability signals align strongly and the fix path is clear; the only missing signals are EPSS and KEV, whose absence should not lower urgency given the act_now label and cluster-admin blast radius. |
| Exploit ScenarioDerived | An attacker holding a valid workspace token starts a sandbox and calls the sandbox file API (upload/download/stat/list/find/replace/delete), supplying a container path whose cleaned result escapes the container root - either via a long run of parent-directory segments after a mount-prefix match or via an absolute symlink followed against the worker root. With AV:N/AC:L and only PR:L, they read the worker pod's Kubernetes service account token and then act as cluster-admin. JFrog reports a working read-only proof that downloaded that token; no standalone public exploit code is referenced in the input. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Nov 01, 2026
Sandbox file API path traversal in Beta9 worker before 0.1.756 lets a tenant holding a valid workspace token and one running sandbox read, write, list and delete arbitrary files on the hosting worker as root, including files belonging to other tenants on the same machine. The reporter's read-only proof pulled the worker pod's Kubernetes service account token through the file API via a path that did not exist inside the sandbox, and because the shipped remote-node manifests bind that service account to cluster-admin, host file access escalates to full cluster compromise, which is why the scope-changed CVSS score reaches 9.9. A proof-of-concept read is described by the reporter; no public exploit code is otherwise confirmed, the issue is not in CISA KEV, and the vendor has released a fix in worker 0.1.756. This is a genuine top-priority issue, not an inflated high-CVSS score.
RemediationAI
Upgrade the Beta9 worker to 0.1.756 or later, which is the vendor-released patch; it re-implements sandbox file operations and workspace sync on top of os.OpenRoot so parent-directory and symlink lookups cannot leave the container root or mount source (release: https://github.com/beam-cloud/beta9/releases/tag/worker-0.1.756, changes: https://github.com/beam-cloud/beta9/pull/1897 and https://github.com/beam-cloud/beta9/commit/a28bf12cf0007c792a25d8ed282b4e8bf6f30393). The same change set hardens volume handling by rejecting volume ids containing '/' or '..' and mount paths containing '..' at mount-configuration time - including volumes persisted in stub configs before validation existed - and by requiring the gateway to confirm that a volume id belongs to the requesting workspace, so those checks should be carried forward rather than reverted. For deployments that cannot move to 0.1.756 immediately, the evidence points to the cluster-admin binding on the worker pod's service account in the shipped remote-node manifests as the amplification factor: reviewing that binding so the worker's service account carries only the permissions it actually needs limits what a successful file-API escape yields, with the trade-off that any cluster-level functionality relying on the broader binding would need its own narrowly scoped role.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Beta9 is an open-source platform for running container sandboxes, and its worker process serves the sandbox file API from outside the container boundary. The vulnerable helper, getHostPathFromContainerPath, translates a tenant-supplied container path into a path on the worker host: when the unresolved path begins with a mount destination - including the default upload mount at /tmp/.beta9 - the remaining segment is appended to that mount's source using filepath.Join, which cleans parent-directory ('..') components only after the prefix check has already succeeded, so a long enough run of those segments resolves to 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 such as /var/run pointing at /run is followed against the worker root rather than the container. This is CWE-22 (improper limitation of a pathname to a restricted directory), and because the resulting file operations run in the worker's context the security scope changes from the tenant's sandbox to the host, giving the assessed CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H vector. Every file-facing operation - upload, download, stat, list, find-in-files, replace-in-files and delete-file - calls the same helper, all reachable with a low-privileged workspace token and no special non-default configuration. The upstream fix in worker 0.1.756 replaces plain path joining with os.OpenRoot for sandbox file operations and workspace sync, so parent-directory and symlink lookups remain confined to the container root or the mount source; the same pull request adds ValidateVolume to reject volume ids containing '/' or '..' and mount paths containing '..', re-validates volumes persisted before validation existed, and makes the gateway resolve volume ids against workspace ownership.
Know when Beta9 Worker gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Network-served file API (AV:N), deterministic traversal (AC:L), needs a workspace token (PR:L), no interaction (UI:N); escapes container to worker-host root as root (S:C, C/I/A:H).
Primary rating from Vendor (JFROG).
CVSS VectorVendor: JFROG
DescriptionCVE.org
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.
Articles & Coverage 1
Executive ViewAI
CVE-2026-120307 in Beta9 worker versions before 0.1.756 allows any tenant with a valid workspace token to read, write, and delete arbitrary files as root on the hosting worker, including files of other tenants, and to escalate to full Kubernetes cluster compromise via the worker's service account. This critically affects all customers on shared infrastructure and the organization's entire cloud environment, requiring immediate leadership attention.
Apply vendor patch.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Path traversal exploits occur when applications use user-controlled input to construct file system paths without proper validation.
More in Beta9 Worker
View allPath traversal in the Beta9 gateway and worker lets a tenant holding a valid workspace token deploy a function, endpoint
Beta9 worker images before 0.1.756 execute every Buildah RUN step from a tenant-supplied image definition with chroot-on
EUVD-2026-114841
GHSA-6h4h-qffc-3gfp
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB