CVE-2026-120306
KrytyczneCVSS 9.9Streszczenie
Beta9 zamienia każdą komendę powłoki w definicji obrazu dzierżawcy na linię RUN w Dockerfile i wykonuje ją za pomocą Buildah na workerze budowania. Obraz workera ustawia BUILDAH_ISOLATION=chroot, a żadne wywołanie buildah nie przekazuje --isolation, więc krok zmienia tylko katalog główny systemu plików, zachowując przestrzenie nazw PID, sieci, IPC i użytkownika workera, działając jako uid 0 z CAP_DAC_OVERRIDE. PID 1 w tym procfs to entrypoint workera, więc /proc/1/root to system plików kontenera workera i jest zapisywalny, zawierając binaria runc, buildah i runsc, token konta usługi Kubernetes oraz katalogi hosta zamontowane w podzie. Pody workera są uprzywilejowane, a warstwowe budowy Clip v2 są domyślne, więc dzierżawca z tokenem workspace może to osiągnąć, przesyłając jedną budowę obrazu.
Ocena ryzyka
Dzierżawca może uzyskać dostęp do systemu plików workera i wykonać dowolne polecenia z uprawnieniami roota, w tym uzyskać token konta usługi Kubernetes i potencjalnie przejąć kontrolę nad klastrem. Podatność dotyczy workerów Beta9 przed wersją 0.1.756.
Rekomendacja
Zaktualizuj workera Beta9 do wersji 0.1.756 lub nowszej, która używa izolacji OCI z prywatnymi przestrzeniami nazw PID, IPC i sieci dla kroków RUN Buildah oraz przekazuje wartości ARG dzierżawcy tylko do kontenera budowania.
Inne podatności w Beta9
Zobacz wszystkie- CVE-2026-120308Krytyczne
W Beta9 dzierżawca może podpiąć wolumen podczas wdrażania funkcji, endpointu lub kolejki zadań. Gateway buduje ścieżkę hosta łącząc katalog główny wolumenów współdzielonych, nazwę workspace i identyfikator wolumenu ze stubu, bez weryfikacji, czy wolumen należy do danego workspace. Segmenty katalogu nadrzędnego w identyfikatorze pozwalają zredukować ścieżkę do katalogu głównego systemu plików workera, który jest montowany w sandboxie z prawem zapisu, umożliwiając odczyt i zapis plików workera, w tym wolumenów innych dzierżawców.
- CVE-2026-120307Krytyczne
Worker Beta9 udostępnia API plików sandboxa spoza kontenera. Funkcja getHostPathFromContainerPath przekształca ścieżkę kontenera dzierżawcy na ścieżkę workera; jeśli nierozwiązana ścieżka zaczyna się od celu montowania (w tym domyślnego /tmp/.beta9), reszta jest dołączana do źródła montowania za pomocą filepath.Join, co czyści segmenty katalogu nadrzędnego po sprawdzeniu prefiksu. Odpowiednio długi ciąg takich segmentów wskazuje dowolną ścieżkę absolutną na workerze, a ścieżka niepasująca do żadnego montowania jest otwierana w systemie plików workera, podążając za dowiązaniami symbolicznymi. Dzierżawca z tokenem workspace i działającym sandboxem może czytać, zapisywać, listować i usuwać pliki na workerze jako root, w tym pliki innych dzierżawców.
Oryginalny opis (angielski, źródło NVD)
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'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's filesystem and is writable. That filesystem contains the runc, buildah, and runsc binaries the worker uses to start tenant containers, the worker'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'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.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS