Prowler CVE-2026-73263: kubeconfig może wykonać kod na workerze

CVE-2026-73263, opublikowane 12 sierpnia 2026 roku, dotyczy platformy bezpieczeństwa chmurowego Prowler. Użytkownik mogący utworzyć lub sprawdzić połączenie dostawcy Kubernetes mógł przesłać kubeconfig zawierający starszy mechanizm gcp auth-provider z polami cmd-path i cmd-args. Biblioteka kliencka Kubernetes wykonywała wskazany program przez subprocess.Popen na współdzielonym workerze Prowlera. W rezultacie nisko uprzywilejowany użytkownik aplikacji mógł osiągnąć wykonanie kodu na hoście.

Podatne są wersje wcześniejsze niż 5.36.0, a wydanie Prowler 5.36.0 zawiera poprawkę. Advisory ocenia problem na 9,9 w CVSS 3.1: dostęp sieciowy, niska złożoność, niskie uprawnienia, brak interakcji i zmiana zakresu z konta tenantowego do współdzielonego workera. Nie ma w źródłach potwierdzenia masowej kampanii.

Dlaczego kubeconfig nie jest biernym plikiem danych

Kubeconfig zwykle kojarzy się z nazwą klastra, adresem API, certyfikatem i kontekstem. Format może jednak zawierać mechanizmy pozyskiwania poświadczeń uruchamiające zewnętrzny program. Współczesne konfiguracje często używają sekcji exec; starszy provider GCP miał odrębne pola polecenia. Klient wywołuje program, aby otrzymać token przed połączeniem z API.

To legalna funkcja na laptopie administratora, który świadomie ufa własnej konfiguracji. Staje się niebezpieczną deserializacją w wielotenantowej usłudze, gdzie użytkownik przesyła YAML, a backend interpretuje go na uprzywilejowanym workerze. Granica formatu nie kończy się na YAML: znaczenie dokumentu obejmuje uruchamianie procesów, odczyt plików i połączenia sieciowe.

Prowler miał kontrolę odrzucającą sekcję exec, lecz nie obejmowała ona legacy gcp auth-provider. To klasyczny problem blokowania jednej reprezentacji niebezpiecznej zdolności zamiast modelowania wszystkich sposobów osiągnięcia skutku. Commit naprawczy rozszerza walidację, aby starsza ścieżka polecenia również nie była interpretowana.

Gdzie przebiegał przepływ ataku

Endpoint /api/v1/providers/{id}/connection przyjmował konfigurację używaną do testu połączenia. Po parsowaniu klient Kubernetes rozpoznawał auth-provider GCP i tworzył źródło tokenu. Jego logika wykonywała program z cmd-path, zanim Prowler mógł bezpiecznie ocenić klaster. Polecenie działało z prawami procesu workera i w jego kontekście sieciowym.

Wpływ zależy zatem od środowiska workera. Może on widzieć sekrety aplikacji, bazę, kolejkę, chmurowe poświadczenia workload identity, socket kontenera albo sieci wewnętrzne. Nie wszystkie instalacje mają taki sam zestaw praw. CVE potwierdza RCE; dostęp do konkretnej chmury czy danych trzeba udowodnić na podstawie konfiguracji.

W modelu SaaS zmiana zakresu jest szczególnie ważna. Użytkownik uprawniony do swojego providera nie powinien wykonywać kodu na warstwie współdzielonej z innymi tenantami. Nawet poprawna autoryzacja endpointu nie wystarcza, jeśli semantyka przyjmowanego dokumentu zawiera instrukcję dla systemu operacyjnego.

Co zrobić teraz

1. Ustal wszystkie instalacje Prowler App/API i ich rzeczywistą wersję, w tym obrazy workerów oraz środowiska testowe.
2. Zaktualizuj do 5.36.0 lub nowszego wspieranego wydania, przebuduj obrazy bez starej warstwy i wymień wszystkie repliki.
3. Do czasu zakończenia aktualizacji ogranicz tworzenie providerów Kubernetes i endpoint testu połączenia do zaufanych administratorów.
4. Wyszukaj przesłane kubeconfigi zawierające auth-provider, gcp, cmd-path, cmd-args albo exec. Traktuj ich zawartość jako wrażliwą i nie kopiuj do zwykłych ticketów.
5. Przejrzyj logi endpointu, procesów workera, EDR, kontenerów, chmury i sieci pod kątem programów potomnych oraz nietypowych połączeń.
6. Jeżeli złośliwa konfiguracja mogła zostać przetestowana, odtwórz workery z zaufanego obrazu i rotuj dostępne im sekrety po usunięciu trwałości.
7. Po aktualizacji wykonaj test negatywny, który potwierdzi odrzucenie obu reprezentacji poleceń bez uruchomienia procesu.

W klastrze Kubernetes samo usunięcie podatnego poda nie wystarczy, jeżeli ten sam stary obraz zostanie pobrany ponownie. Przypnij poprawiony digest, usuń podatną wersję z manifestów i sprawdź kolejki, w których mogły pozostać zadania. Autoscaler może utworzyć nowy worker z nieaktualnego template’u długo po zakończeniu głównego wdrożenia.

Jak zbadać możliwe skutki

Najpierw wyznacz okno: od pierwszej dostępności podatnego endpointu do wymiany ostatniego workera. Połącz identyfikator użytkownika i providera z ID zadania, poda oraz noda. Szukaj procesów potomnych procesu aplikacji, które nie należą do normalnego zestawu narzędzi. Nietypowy interpreter, klient sieciowy, zapis w /tmp lub próba odczytu tokenu service account są sygnałami do rozszerzenia analizy.

Następnie zinwentaryzuj uprawnienia. Sprawdź zmienne środowiskowe, mounty Secret, projected service account token, rolę IAM, dostęp do metadanych, socket Dockera i reguły egress. To określa wiarygodny blast radius. Nie rotuj w ciemno wszystkiego, ale nie pomijaj krótkowiecznych poświadczeń: ich użycie mogło utworzyć długowieczny zasób, nowe konto lub klucz.

W logach chmury szukaj działań tożsamości workera w nietypowym czasie, nowych credentiali, zmian polityk, odczytów sekretów i wywołań z nieznanego adresu. W bazie Prowlera sprawdź zmiany providerów oraz dostęp do danych innych tenantów. Jeżeli worker był współdzielony, dochodzenie powinno rozważyć naruszenie izolacji nawet bez bezpośredniego dowodu odczytu każdego rekordu.

Bezpieczne przetwarzanie kubeconfigów

Najsilniejszym projektem jest nie wykonywać żadnych pluginów poświadczeń z dokumentu użytkownika. Usługa może zaakceptować tylko statyczny, ograniczony zestaw pól, a uwierzytelnienie do klastra realizować własnym mechanizmem po stronie serwera. Allowlista schematu jest lepsza niż rosnąca lista zabronionych kluczy, ponieważ format i biblioteka mogą dodać kolejną ścieżkę efektu ubocznego.

Jeżeli zgodność wymaga pełnej konfiguracji, analiza powinna odbywać się w jednorazowej piaskownicy bez sekretów, z read-only filesystem, bez możliwości eskalacji, z ograniczonym CPU i pamięcią oraz domyślnie zablokowanym egress. Nie jest to zamiennik walidacji — tylko kolejna warstwa, gdy nowa semantyka ominie filtr.

Worker nie powinien współdzielić z API szerokiej tożsamości chmurowej. Osobne konta, krótkie tokeny, minimalne role i segmentacja zmniejszają skutek RCE. Per-tenant isolation może być uzasadnione dla wysokiego ryzyka, ale wymaga oceny kosztu. Co najmniej zadania przyjmujące aktywne konfiguracje powinny być oddzielone od procesu przechowującego sekrety platformy.

Testy, które obejmują zdolność, nie nazwę pola

Regresja powinna zebrać wszystkie wspierane mechanizmy auth z dokumentacji klienta Kubernetes i udowodnić, że żaden nie uruchamia procesu w kontekście serwera. Instrumentuj subprocess, dostęp do plików i sieci, a test uznaj za nieudany przy każdym nieoczekiwanym efekcie. Dodaj corpus z legacy konfiguracjami, bo właśnie rzadziej używana ścieżka ominęła pierwotną kontrolę.

Przegląd zależności powinien śledzić także zmiany semantyczne bibliotek: upgrade klienta Kubernetes może włączyć nową obsługę providera bez zmiany kodu aplikacji. Test właściwości „parsowanie nie wykonuje kodu” jest trwalszy niż test „pole exec jest blokowane”.

Fakty o endpointcie, legacy providerze, subprocess.Popen, wersji naprawczej i wyniku CVSS pochodzą z advisory Prowler oraz commitu. Zalecenia izolacji, rotacji i testów są analizą Breachroad. Publiczne źródła nie potwierdzają aktywnej kampanii.

Zamknięcie zadania powinno zawierać digest poprawionego obrazu i wynik negatywnego testu obu mechanizmów uwierzytelnienia.

Ten przypadek łączy AppSec, Kubernetes i bezpieczeństwo wielotenantowe, dlatego jest dobrym materiałem na wspólne ćwiczenie. Szkolenia cyberbezpieczeństwa dla organizacji pomagają zespołom rozpoznawać aktywne formaty konfiguracji. Niezależny audyt bezpieczeństwa chmury może ocenić izolację workerów, IAM i obsługę sekretów.