CVE-2026-44180

Jupyter Enterprise Gateway — obejście ograniczenia UID/GID i eskalacja do root

CVSS 9.8v3.1pub. 2026-07-16upd. 2026-08-05

Podatność w Jupyter Enterprise Gateway pozwala atakującemu na ominięcie mechanizmu blokującego uruchamianie kerneli z uprawnieniami roota (UID/GID 0) poprzez spreparowane wartości KERNEL_UID lub KERNEL_GID. Jest to szczególnie niebezpieczne w środowiskach kontenerowych, gdyż może prowadzić do container escape i przejęcia całego klastra Kubernetes.

▸ Pokaż oryginał (EN)

Jupyter Enterprise Gateway launches remote Jupyter Notebook kernels across distributed clusters like Apache Spark, Kubernetes, and Docker Swarm. Versions 2.0.0rc1 and above prior to 3.3.0 have a prohibited UID and GID feature that by default prevents launching kernels with UID or GID 0 (root), and this restriction can be bypassed using a specially crafted KERNEL_UID or KERNEL_GID value. This input validation vulnerability allows running Jupyter kernels as root, which can be dangerous as it allows more attack surface, and may lead to container escapes, compromising the worker node and all workloads running on it. Repeated exploitation can compromise all worker nodes, and thus the entire Kubernetes cluster. It is possible to specify volume mounts, so one vector for a container escape is to use a hostPath R/W volume mount, use this UID/GID bypass to run as root, and then gain code execution in the underlying worker node by creating a crontab entry in the mounted host file system. This issue has been fixed in version 3.0.0.

🤖 Analiza AI

Jak działa

Jupyter Enterprise Gateway posiada mechanizm blokujący uruchamianie kerneli z UID lub GID równym 0 (root). Błąd polega na niewystarczającej walidacji wejścia (CWE-20) — atakujący może przesłać specjalnie spreparowaną wartość parametru KERNEL_UID lub KERNEL_GID, która omija tę weryfikację i powoduje uruchomienie kernela z uprawnieniami roota. Będąc rootem wewnątrz kontenera, atakujący może następnie zamontować hostPath jako wolumin z prawem zapisu i odczytu, a następnie uzyskać wykonanie kodu na węźle roboczym (np. przez dodanie wpisu crontab w zamontowanym systemie plików hosta). Wielokrotne wykorzystanie tej podatności może prowadzić do kompromitacji wszystkich węzłów roboczych, a tym samym całego klastra Kubernetes.

Skutki

Atakujący może uruchomić kernel Jupyter z uprawnieniami roota, co otwiera drogę do container escape, przejęcia węzła roboczego oraz wszystkich uruchomionych na nim obciążeń. W środowisku Kubernetes możliwa jest kompromitacja całego klastra.

Mitygacja

Należy zaktualizować Jupyter Enterprise Gateway do wersji 3.3.0 lub nowszej, w której podatność została usunięta. Jako środek zaradczy należy ograniczyć dostęp sieciowy do API Enterprise Gateway wyłącznie do zaufanych użytkowników oraz unikać konfiguracji z hostPath volume mountami o szerokich uprawnieniach.

Kogo dotyczy

Jupyter Enterprise Gateway w wersjach od 2.0.0rc1 do poniżej 3.3.0, działający w środowiskach klastrowych takich jak Apache Spark, Kubernetes lub Docker Swarm.

Uwagi

Opis techniczny wskazuje konkretny wektor container escape: użycie hostPath R/W volume mount w połączeniu z ominiętym ograniczeniem UID/GID w celu dodania wpisu crontab na hoście. Podatność jest naprawiona w wersji 3.3.0 zgodnie z opisem EN (choć opis wspomina również wersję 3.0.0 jako pierwszą z poprawką — zalecane jest zastosowanie wersji 3.3.0 zgodnie z referencjami do wydania).