KubePi CVE-2026-65956: publiczne API SSO otwierało drogę do przejęcia panelu Kubernetes

CVE-2026-65956 dotyczy KubePi, panelu zarządzającego wieloma klastrami Kubernetes. W wersjach do 1.6.15 włącznie publiczna granica routingu potrzebna do logowania SSO obejmowała również operacje administracyjne. Odczyt, tworzenie, modyfikacja konfiguracji SSO/OIDC/SAML i test połączenia nie były poprawnie ograniczone do administratora. W określonych konfiguracjach pozwalało to wpłynąć na globalny proces logowania, przejąć konto lub podnieść uprawnienia, a funkcję testową wykorzystać jako prymityw SSRF.

Rekord CVE został opublikowany 26 sierpnia o 22:40 UTC, czyli 27 sierpnia czasu polskiego. Zawiera CVSS 4.0 10,0 (Critical), podczas gdy strona GHSA nadal wyświetla etykietę Moderate. To realna rozbieżność między metryką dołączoną do rekordu a etykietą interfejsu advisory. Nie należy jej ukrywać ani arbitralnie wybierać korzystniejszej oceny. Dla zespołu operacyjnego ważniejsze są warunki i możliwy blast radius: panel może posiadać poświadczenia oraz uprawnienia do wielu klastrów.

Błąd architektury tras, nie samego OIDC

SSO wymaga kilku endpointów dostępnych bez wcześniejszej sesji. Użytkownik musi rozpocząć logowanie, wrócić na callback dostawcy tożsamości, pobrać status lub przejść przez SAML ACS. Publiczność tych tras jest zamierzona. Problem powstaje, gdy ten sam router lub middleware obejmuje także funkcje zmieniające zaufanie: adres issuer’a, client ID, sekrety, mapowanie atrybutów, metadata SAML albo test połączenia.

W KubePi publiczna granica obejmowała za dużo operacji. Advisory wskazuje, że nieuprawniony lub nisko uprzywilejowany użytkownik mógł odczytać albo zmienić globalną konfigurację. To narusza rozdział data plane logowania od control plane tożsamości. Fakt, że oba zestawy endpointów mają prefiks „SSO”, nie oznacza, że powinny dziedziczyć tę samą politykę.

Poprawka w 2.0.0 pozostawia publiczne tylko endpointy potrzebne do login, callback, statusu oraz przepływów SAML. Odczyt, tworzenie, aktualizacja i test konfiguracji trafiają za kontrolę administratora. Dodano minimalny publiczny endpoint, który przekazuje ekranowi logowania wyłącznie wymagany typ uwierzytelniania, zamiast pełnego obiektu konfiguracyjnego.

Jak zmiana konfiguracji prowadzi do takeover

Konfiguracja OIDC lub SAML mówi aplikacji, komu ufać i jak interpretować otrzymaną tożsamość. Jeśli atakujący może skierować ją do kontrolowanego issuer’a, podmienić metadata, zmienić mapowanie identyfikatora lub inne parametry zaufania, może doprowadzić do zaakceptowania własnej odpowiedzi jako tożsamości uprzywilejowanej. Dokładny łańcuch zależy od aktywnego providera, walidacji podpisu, mapowania użytkowników i ról.

Advisory celowo używa sformułowania „under certain conditions”. Nie każda modyfikacja oznacza natychmiastowego administratora. Wdrożenie może mieć SSO wyłączone, wymagać istniejącego użytkownika albo mapować wszystkie nowe tożsamości do roli minimalnej. Nadal jednak możliwość zmiany globalnej kotwicy zaufania przez osobę bez uprawnień jest krytycznym naruszeniem kontroli.

KubePi zarządza klastrami i namespace’ami przypisanymi użytkownikom. Przejęcie konta administratora panelu nie jest automatycznie tożsame z uprawnieniami cluster-admin w każdym podłączonym klastrze, lecz pozwala wykorzystać dokładnie te kubeconfigi, service accounty i role, które panel otrzymał. Dlatego ocenę skutku trzeba wykonać per cluster, a nie kończyć na bazie użytkowników KubePi.

SSRF przez test połączenia

Funkcja connectivity test musi wysłać żądanie z serwera KubePi do wskazanego endpointu SSO. Gdy adres jest kontrolowany przez użytkownika bez uprawnień, serwer staje się pośrednikiem dostępu do sieci wewnętrznej. Może to umożliwić skanowanie usług, odczyt odpowiedzi z paneli administracyjnych albo kontakt z endpointami metadata, zależnie od protokołu, redirectów i tego, czy odpowiedź wraca do wywołującego.

Advisory określa zachowanie jako server-side request risk i nie dokumentuje dostępu do konkretnej usługi chmurowej. Nie należy dopisywać potwierdzonego wycieku credentiali bez dowodu. W modelu zagrożeń trzeba jednak przyjąć, że proces panelu ma pozycję sieciową uprzywilejowaną względem anonimowego klienta.

Poza kontrolą roli warto stosować pozytywną walidację schematu i hosta, blokować loopback, link-local oraz prywatne zakresy, ponownie sprawdzać każdy redirect i rozwiązywać DNS w sposób odporny na rebinding. Najbezpieczniejszy test działa przez dedykowany egress proxy z allowlistą dostawców tożsamości i ograniczonym czasem odpowiedzi.

Nadmiarowe pola w API użytkowników

Advisory opisuje też API listujące użytkowników, które nie zawsze usuwało pola związane z uwierzytelnianiem. Nie oznacza to, że zwracany był plaintext hasła. Ryzyko zależy od konkretnych pól i ich użyteczności. Zasada jest jednak prosta: serializacja domenowego obiektu użytkownika bez jawnego DTO często ujawnia więcej, niż potrzebuje ekran administracyjny.

Poprawka czyści pola auth przed zwróceniem listy. Dobrą praktyką jest model odpowiedzi tworzony przez pozytywną listę: identyfikator, nazwa, status i niezbędne role. Nowe pole dodane do modelu bazy nie powinno automatycznie pojawić się w API. Test kontraktu może blokować regresję, jeżeli w JSON znajdą się hashe, sekrety, tokeny, recovery codes lub wewnętrzne identyfikatory providera.

Zakres wersji i konsekwencje migracji

Podatne są wydania do 1.6.15 włącznie, a poprawiona linia zaczyna się od 2.0.0. To skok wersji głównej, więc aktualizacji nie należy traktować jak wymiany jednego pliku binarnego. Repozytorium podaje, że KubePi 2.0.0 używa Go 1.26 i Kubernetes client-go 0.36, wspiera Kubernetes od 1.24, a jako rekomendowane wymienia 1.34–1.36.

Przed migracją zinwentaryzuj wersje podłączonych klastrów, metody SSO, kubeconfigi, role, namespace’y i integracje API. Wykonaj kopię konfiguracji oraz bazy zgodnie z dokumentacją produktu, przetestuj callback URI i metadata SAML w środowisku przedprodukcyjnym. Nie przywracaj starego obrazu po migracji na tej samej bazie bez planu kompatybilności schematu.

Jeśli aktualizacja nie może wejść od razu, odetnij panel od internetu, ogranicz dostęp na reverse proxy lub VPN do zaufanych administratorów i zablokuj zarządzające endpointy SSO. Sama blokada menu w frontendzie nie jest zabezpieczeniem. Reguła musi działać na warstwie ingress/WAF i obejmować wszystkie metody HTTP, wersje API oraz zakodowane warianty ścieżki.

Weryfikacja po wdrożeniu

Testuj osobno użytkownika anonimowego, zwykłego i administratora. Anonimowy powinien zobaczyć wyłącznie minimalną informację potrzebną do wyboru SSO oraz używać login/callback. Próby odczytu, utworzenia, zmiany i testu konfiguracji muszą zakończyć się odmową. Zwykły użytkownik również nie może wykonać operacji zarządzających ani zobaczyć pełnej konfiguracji.

Po udanym logowaniu sprawdź mapowanie użytkownika, grup i ról oraz skuteczny dostęp do każdego klastra. Negatywny test powinien użyć poprawnie podpisanej tożsamości, która nie ma mapowania administratora. Dla SAML sprawdź issuer, audience, recipient i ważność; dla OIDC — issuer, audience, nonce/state, algorytm podpisu i pobieranie JWKS.

Obserwuj błędy 401/403, zmiany konfiguracji SSO i outbound traffic procesu KubePi. Alarm powinien objąć każde zarządzanie tożsamością poza oknem zmian, nowy issuer, zmianę callbacku, test do prywatnego adresu oraz pierwsze logowanie administratora przez nowego providera.

Reakcja, jeżeli panel był publiczny

Zachowaj logi reverse proxy, aplikacji, dostawcy SSO i Kubernetes audit logs. Ustal, czy ktokolwiek odczytywał lub modyfikował konfigurację, wykonywał connectivity test albo listował użytkowników. Porównaj bieżące wartości z zatwierdzoną konfiguracją IaC lub kopią i sprawdź historię nowych sesji administracyjnych.

Jeśli nie można wykluczyć takeover, zmień client secrets SSO, unieważnij sesje KubePi i zrotuj kubeconfigi lub tokeny service account dostępne panelowi. Następnie przejrzyj działania w klastrach: tworzenie ClusterRoleBinding, sekretów, workloadów uprzywilejowanych, webhooków admission i zmian obrazów. Rotacja KubePi bez analizy Kubernetes może zostawić trwałość poza samym panelem.

Fakty źródłowe i wnioski Breachroad

Zakres wersji, publiczne operacje SSO, ryzyko takeover/eskalacji, SSRF, pola API użytkowników i sposób naprawy pochodzą z advisory KubePi oraz rekordu CVE. CVSS 10,0 pochodzi z danych CVE, a etykieta Moderate z widoku GHSA; rozbieżność została zachowana. Źródła nie podają aktywnej eksploatacji. Zalecenia segmentacji, detekcji, rotacji i przeglądu audit logs są wnioskami Breachroad.

Szkolenia z bezpieczeństwa chmury, Kubernetes i tożsamości pomagają zespołom rozdzielać publiczny login od administracyjnego control plane, a audyty aplikacji oraz infrastruktury mogą zweryfikować endpointy SSO, SSRF i rzeczywisty blast radius panelu.

Źródła

• KubePi — GHSA-wjrh-4j52-c664 / CVE-2026-65956
• KubePi — commit naprawczy b62b41f
• KubePi — wydanie 2.0.0
• KubePi — repozytorium i kompatybilność 2.0
• NVD — CVE-2026-65956