Beta9 Worker EUVD-2026-114841

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.

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.

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.