<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>VulnFeed.org: beam-cloud Beta9 worker</title><link>https://vulnfeed.org/</link><description>Every disclosure, as it lands. Critical-only feed available.</description><language>en</language><atom:link href="https://vulnfeed.org/feed/product/beam-cloud-beta9-worker.xml" rel="self" type="application/rss+xml"/><item><title>CVE-2026-120306: Beta9 build sandbox escape via chroot-only isolation</title><link>https://vulnfeed.org/cve/CVE-2026-120306/</link><guid isPermaLink="true">https://vulnfeed.org/cve/CVE-2026-120306/</guid><pubDate>Sun, 01 Nov 2026 13:18:01 +0000</pubDate><description>Beta9 turns each shell command in a tenant image definition into a Dockerfile RUN line and executes it with Buildah on the build worker. The worker image sets BUILDAH_ISOLATION=chroot, and no buildah invocation passes --isolation, so the step only changes its filesystem root. It keeps the worker pod&apos;s PID, network, IPC, and user namespaces, runs as uid 0, and holds CAP_DAC_OVERRIDE. PID 1 in that procfs is the worker entrypoint, so /proc/1/root is the worker container&apos;s filesystem and is writable. That filesystem contains the runc, buildah, and runsc binaries the worker uses to start tenant containers, the worker&apos;s Kubernetes service account token, and the host directories mounted into the pod. Worker pods are privileged. Clip v2 layered builds are the default, so a tenant with a workspace token reaches this by submitting one image build. The read-only proof confirmed the shared namespaces, CAP_DAC_OVERRIDE, and that the worker&apos;s runc binary is visible at /proc/1/root. Fixed in worker 0.1.756: Buildah RUN steps, including the WORKDIR mkdir, use OCI isolation with private PID, IPC, and network namespaces, and tenant ARG values are passed only into the build container.</description></item><item><title>CVE-2026-120307: Beta9 container escape via unvalidated sandbox file paths</title><link>https://vulnfeed.org/cve/CVE-2026-120307/</link><guid isPermaLink="true">https://vulnfeed.org/cve/CVE-2026-120307/</guid><pubDate>Sun, 01 Nov 2026 13:18:01 +0000</pubDate><description>The Beta9 worker serves the sandbox file API from outside the container. getHostPathFromContainerPath turns the tenant&apos;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&apos;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&apos;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&apos;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.</description></item></channel></rss>
