Beta9 Worker
Monthly
Path traversal in the Beta9 gateway and worker lets a tenant holding a valid workspace token deploy a function, endpoint, or task queue with a volume identifier containing '..' segments, collapsing the gateway-built host path to the worker's filesystem root and bind-mounting it read-write into the sandbox. This allows an authenticated attacker to read and write the worker's files, including other tenants' volumes colocated on the same machine; CVSS 3.1 is 9.9 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H) with scope change. Gateway 0.1.769 and worker 0.1.745 are confirmed vulnerable, with fixes released in gateway 0.1.776 and worker 0.1.756; no public exploit code was identified at time of analysis, but the vendor-supplied patch details are public and the priority label is act_now.
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.
Beta9 worker images before 0.1.756 execute every Buildah RUN step from a tenant-supplied image definition with chroot-only isolation, so a build submitted with an ordinary workspace token runs as uid 0 inside the worker pod's PID, network, IPC and user namespaces while retaining CAP_DAC_OVERRIDE. Because /proc/1/root resolves to the worker container's writable filesystem, that tenant build can reach the runc, buildah and runsc binaries the worker uses to launch other tenants' containers, the worker's Kubernetes service account token, and host directories mounted into the privileged pod, giving scope-changed confidentiality, integrity and availability impact (CVSS 9.9, S:C). The reporter documented a read-only proof confirming the shared namespaces and the worker's runc binary at /proc/1/root; no public exploit code is confirmed, and the vendor shipped the fix in worker 0.1.756.
Path traversal in the Beta9 gateway and worker lets a tenant holding a valid workspace token deploy a function, endpoint, or task queue with a volume identifier containing '..' segments, collapsing the gateway-built host path to the worker's filesystem root and bind-mounting it read-write into the sandbox. This allows an authenticated attacker to read and write the worker's files, including other tenants' volumes colocated on the same machine; CVSS 3.1 is 9.9 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H) with scope change. Gateway 0.1.769 and worker 0.1.745 are confirmed vulnerable, with fixes released in gateway 0.1.776 and worker 0.1.756; no public exploit code was identified at time of analysis, but the vendor-supplied patch details are public and the priority label is act_now.
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.
Beta9 worker images before 0.1.756 execute every Buildah RUN step from a tenant-supplied image definition with chroot-only isolation, so a build submitted with an ordinary workspace token runs as uid 0 inside the worker pod's PID, network, IPC and user namespaces while retaining CAP_DAC_OVERRIDE. Because /proc/1/root resolves to the worker container's writable filesystem, that tenant build can reach the runc, buildah and runsc binaries the worker uses to launch other tenants' containers, the worker's Kubernetes service account token, and host directories mounted into the privileged pod, giving scope-changed confidentiality, integrity and availability impact (CVSS 9.9, S:C). The reporter documented a read-only proof confirming the shared namespaces and the worker's runc binary at /proc/1/root; no public exploit code is confirmed, and the vendor shipped the fix in worker 0.1.756.