Beta9 Worker EUVD-2026-114840

Requires a valid tenant workspace token (authenticated, PR:L) on a Beta9 deployment running an affected worker (before 0.1.756); no user interaction is needed. Exploitation works against the DEFAULT configuration: Clip v2 layered builds are the default, the worker image sets BUILDAH_ISOLATION=chroot, no buildah invocation passes --isolation, and worker pods are privileged, so a single image build containing a shell RUN command is sufficient. The concrete prerequisite is that Buildah RUN steps execute with chroot-only isolation sharing the worker pod's PID/network/IPC/user namespaces as uid 0 with CAP_DAC_OVERRIDE. Limiting factors: the attacker must already be able to submit builds in a workspace (tenant-level auth), and deployments on worker 0.1.756+ are not exploitable because RUN steps then use OCI isolation with private PID/IPC/network namespaces and tenant ARG values are passed only into the build container.

This is a genuine high-priority issue, not a CVSS-inflated one. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H = 9.9) is well supported by the described mechanism: a tenant holding only a workspace token submits a single image build and, because Buildah RUN steps run under BUILDAH_ISOLATION=chroot with no --isolation override, the step shares the worker pod's PID/network/IPC/user namespaces, runs as uid 0, and holds CAP_DAC_OVERRIDE, making /proc/1/root (the worker container filesystem, including runc/buildah/runsc binaries, the worker's Kubernetes service account token, and host mounts) readable and writable - a scope-changing escape from the intended build sandbox into the privileged worker pod and node. The vuln.today decision label is act_now and JFrog reported it with a read-only proof that confirmed the shared namespaces, CAP_DAC_OVERRIDE, and visibility of the worker's runc binary at /proc/1/root, so the core preconditions are verified rather than inferred. Signals that would normally raise or confirm urgency further are missing from the input: no EPSS probability is provided, the CVE is not listed in CISA KEV, and no public exploit-code reference is supplied, so there is no evidence of active or widespread exploitation despite the act_now label. Net: authenticated-tenant-to-node/cluster compromise in the default configuration of a multi-tenant build platform - high real risk for any exposed Beta9 deployment, with the main uncertainty being exploitation likelihood in the wild rather than exploitability itself.

A tenant who possesses a valid workspace token submits one image build whose definition contains a shell command; Beta9 turns that command into a Dockerfile RUN line and executes it with Buildah under chroot-only isolation. Because the RUN step keeps the worker pod's namespaces and runs as uid 0 with CAP_DAC_OVERRIDE, the command reads the worker's Kubernetes service account token and overwrites the worker's runc/buildah binaries via the writable /proc/1/root, pivoting from the build sandbox to the privileged worker pod and the underlying node. No public exploit code is referenced, but JFrog's read-only proof confirmed the enabling conditions, and AV:N/AC:L/PR:L/UI:N means exploitation needs only a low-privilege tenant and a default-configuration build submission.