CVE-2026-77596

W Kubeflow Pipelines przed wersją 2.16.1 serwer API w trybie wieloużytkownikowym traktuje pustą przestrzeń nazw używaną przez współdzielone lub globalne pipeline'y jako wyjątek autoryzacyjny dla operacji modyfikacji i usuwania. Uwierzytelniony użytkownik może modyfikować lub usuwać współdzielone definicje i wersje pipeline'ów bez wymaganych uprawnień Kubernetes RBAC, naruszając ich integralność i dostępność.

W Kubeflow Pipelines przed wersją 2.18.0 ścieżka pobierania artefaktów frontendu dla source=s3 lub source=minio akceptuje providerInfo.Params.endpoint, a ścieżka logów podów akceptuje metadane punktu końcowego S3 z statusu workflow, bez wymagania zgodności z konfiguracją przechowywania operatora. W domyślnej konfiguracji standalone z wyłączoną autoryzacją nieuwierzytelniony wywołujący może zmusić współdzielony pod ml-pipeline-ui do połączenia z dowolnymi osiągalnymi hostami i zwrócenia danych odpowiedzi.

W Kubeflow Pipelines przed wersją 2.18.0 trasa frontendu GET /artifacts/get akceptuje source=http lub source=https z kontrolowanymi przez wywołującego wartościami bucket i key, a isAllowedResourceName zezwala na w pełni cyfrowy host dziesiętny, który parser URL konwertuje na adres IPv4. Domyślny ALLOWED_ARTIFACT_DOMAIN_REGEX i konfiguracja standalone z wyłączoną autoryzacją pozwalają nieuwierzytelnionemu wywołującemu pobierać wewnętrzne zasoby HTTP i odbierać ich treść odpowiedzi.

Kubeflow Pipelines przed wersją 2.17.0 zawiera nieuwierzytelnioną podatność SSRF w trasie /_proxy/ w frontend/server/proxy-middleware.ts. Funkcja _routePathWithReferer() akceptuje dowolny adres URL HTTP lub HTTPS kontrolowany przez atakującego i przekazuje go do createProxyMiddleware bez listy dozwolonych hostów ani filtrowania adresów loopback, link-local, RFC1918 czy klastrowych. Trasa jest dostępna bez autoryzacji, co pozwala na przekazywanie żądań do wewnętrznych usług i zwracanie odpowiedzi atakującemu. Problem naprawiono w wersji 2.17.0.

W Kubeflow Pipelines przed wersją 2.18.0 serwer API dekompresował przesyłane archiwa pipeline'ów bez odpowiedniego ograniczenia rozmiaru rozpakowywanych danych podczas lokalizowania lub odczytu pliku pipeline'u. Małe archiwum ZIP lub tar skompresowane gzipem może zużyć nieproporcjonalnie dużo pamięci i wyczerpać zasoby serwera API. Przetwarzanie przesyłania wieloczęściowego pipeline'ów i wersji pipeline'ów wykonuje dekompresję przed autoryzacją przestrzeni nazw, więc osiągalny wywołujący nie potrzebuje pozytywnej decyzji autoryzacyjnej o utworzeniu pipeline'u. Problem naprawiono w wersji 2.18.0.

W Kubeflow Pipelines od wersji 0.5.1 do 2.17.0 trasy artefaktów frontendu nie sprawdzały, czy uwierzytelniony użytkownik ma uprawnienia do żądanej przestrzeni nazw. Użytkownik znający lokalizację artefaktu mógł wybrać przestrzeń nazw innego tenanta lub pominąć ją, aby odczytać zawartość artefaktów, takie jak zbiory danych, modele lub wyniki potoków.

W Kubeflow Pipelines przed wersją 2.18.0 handler GET /apis/v1alpha1/runs/{run_id}/nodes/{node_id}/log pobierał logi bez sprawdzenia uprawnień wywołującego do wskazanego runu. Osoba znająca identyfikator runu i poda/noda mogła odczytać logi z uprawnieniami serwera API, a w przypadku logów na żywo identyfikator noda był przyjmowany jako nazwa poda bez weryfikacji przynależności do runu.

W Kubeflow Pipelines przed wersją 2.18.0 handler artefaktów GET /artifacts/get?source=volume nie ograniczał ścieżki pliku podanej przez wywołującego do wybranego wolumenu. Osoba znająca zamontowany wolumen mogła użyć path traversal do odczytu plików poza nim, jeśli proces serwujący artefakty miał do nich dostęp.