CVE-2026-105223: klient Kubernetes w PHP i brak weryfikacji TLS

5 października opublikowano CVE-2026-105223 dotyczący biblioteki PHP maclof/kubernetes-client od 0.17.0 do wersji poniżej 0.32.0. Problem występuje przy przetwarzaniu kubeconfig bez certificate-authority-data: klient mógł wyłączać weryfikację certyfikatu mimo adresu HTTPS i pomijać ustawienie insecure-skip-tls-verify.

To publikacja rekordu dla wcześniej zgłoszonego błędu. Zgłoszenie badacza pochodzi z 18 czerwca, a wydanie 0.32.0 z 2 września wymienia usunięcie niebezpiecznego zachowania przy braku danych CA. Nie jest to informacja o podatności wszystkich klientów Kubernetes ani o nowym włamaniu do klastra.

Ważna różnica w opisie zakresu

Oryginalne zgłoszenie badacza wskazuje ścieżkę WebSocket i wyłączenie sprawdzania certyfikatu oraz nazwy serwera. Wymienia między innymi operacje exec, attach i port-forward; zwykłe wywołania HTTP CRUD przez PSR-18 oznacza jako nieobjęte opisanym problemem. Rekord CVE używa szerszego sformułowania obejmującego WebSocket lub REST.

Dlatego w ocenie własnej aplikacji należy sprawdzić rzeczywiście używany transport, wersję i konfigurację. Podajemy tę różnicę jawnie, zamiast przenosić jeden opis na wszystkie operacje. Atakujący znajdujący się na drodze połączenia może podszyć się pod API server i przechwycić poświadczenia. Potencjalne działania zależą od ich uprawnień; przejęcie tokenu nie oznacza automatycznie roli cluster-admin.

Dlaczego sam HTTPS nie zamyka oceny

Wniosek Breachroad: przegląd połączenia powinien obejmować zarówno szyfrowanie, jak i potwierdzenie tożsamości odbiorcy. Numer portu, schemat adresu i udane połączenie nie są wystarczającymi dowodami poprawnej weryfikacji.

W praktycznej ocenie zespół powinien wskazać, skąd pochodzi zaufanie do CA, czy sprawdzana jest nazwa serwera i czy błąd certyfikatu blokuje przekazanie poświadczeń. Jeżeli aplikacja ma kilka sposobów komunikacji z API, sprawdź każdy używany wariant. Udana kontrola jednego klienta HTTP nie zamyka oceny innego transportu.

Pięć działań dla właściciela integracji

1. Zidentyfikuj zależność. Sprawdź pakiet w pliku blokady zależności oraz wersję w rzeczywiście działającym obrazie. Uwzględnij narzędzia administracyjne i usługi pomocnicze.
2. Wdróż poprawkę. Wybierz wspieraną wersję zawierającą naprawę z 0.32.0. Nota wydania opisuje również zmiany klas repozytoriów; przejrzyj bezpośrednie importy i własne rozszerzenia przed aktualizacją.
3. Potwierdź odmowę połączenia. W izolowanym środowisku z nieszkodliwymi danymi sprawdź, czy niezaufany certyfikat oraz niezgodna nazwa serwera przerywają używaną ścieżkę komunikacji.
4. Napraw źródło zaufania. Dostarcz właściwą konfigurację CA i nazwy serwera. Nie rozwiązuj błędu certyfikatu przez wyłączenie weryfikacji.
5. Oceń tokeny. Ustal ich zakres, odbiorców i czas użycia. Jeśli są przesłanki przechwycenia, uruchom procedurę incydentową, wymianę poświadczeń i przegląd operacji API.

To proponowana procedura kontroli Breachroad. Nie zalecamy testowania przechwytywania ruchu z prawdziwym tokenem produkcyjnym ani uznawania samej instalacji podatnej wersji za dowód wycieku.

Przykład szkoleniowy: odczyt zasobów działa, konsola też

W naszym fikcyjnym przykładzie panel poprawnie pobiera listę zasobów przez klienta HTTP. Osobna funkcja konsoli używa WebSocket. Tester sprawdził tylko listę, więc raport nie zawiera odpowiedzi, czy konsola odrzuci nieprawidłowy certyfikat.

Zadanie dla zespołu polega na dopisaniu brakującego dowodu oraz wskazaniu właściciela transportu i konfiguracji. Rezultatem ma być mapa połączeń i warunków odmowy, nie udany pokaz przechwycenia sekretu. Taki sposób pracy można zastosować również podczas przeglądu innych integracji.

Szkolenia z cyberbezpieczeństwa dla zespołów IT pomagają przećwiczyć ocenę konfiguracji i odpowiedzialność za poprawki. Podstawy znajdziesz w materiałach o TLS, mTLS i PKI oraz uprawnieniach RBAC w Kubernetes.

Źródła i wnioski Breachroad

Daty i zakres wersji pochodzą z rekordu CVE. Szczegóły ścieżki WebSocket podaje badacz, a naprawę i wymagania migracji opisuje projekt. Różnicę zakresu między źródłami zachowujemy w ocenie. Plan działań i fikcyjny przykład są rekomendacjami Breachroad. Źródła sprawdziliśmy 5 października 2026 roku.