CVE-2026-69129
ŚrednieCVSS 5.8Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 15 - wyżej niż 15% wszystkich znanych CVE
Streszczenie
KubePi do wersji 2.0.0 włącznie nie sprawdza spójnie uprawnień do klastrów w API działającym na poziomie klastra. Uwierzytelniony użytkownik z uprawnieniami do zarządzania klastrem może operować na klastrach spoza przyznanego zakresu. Problem został naprawiony w wersji 2.0.1.
Ocena ryzyka
Ryzyko nieautoryzowanego dostępu do danych i modyfikacji w klastrach Kubernetes, którymi użytkownik nie powinien zarządzać, co może prowadzić do naruszenia poufności i integralności.
Rekomendacja
Zaleca się natychmiastową aktualizację KubePi do wersji 2.0.1 lub nowszej oraz przegląd konfiguracji ról i klastrów pod kątem nadmiernych uprawnień.
Inne podatności w KubePi
Zobacz wszystkie- CVE-2026-65956Krytyczne
KubePi w wersjach do 1.6.15 włącznie udostępnia punkty API konfiguracji SSO na tym samym publicznym routerze co punkty logowania i wywołań zwrotnych SSO, co pozwala na zarządzanie SSO, OIDC i SAML bez autoryzacji administratora. Nieautoryzowany użytkownik może przeglądać lub zmieniać konfigurację uwierzytelniania, co może prowadzić do przejęcia konta lub eskalacji uprawnień. Funkcja testowania połączenia SSO może być wykorzystana jako SSRF, a API listy użytkowników nie czyści pól związanych z uwierzytelnianiem. Problem naprawiono w wersji 2.0.0.
- CVE-2023-37917Krytyczne
KubePi to otwartoźródłowy panel zarządzania Kubernetes. Zwykły użytkownik ma uprawnienia do tworzenia/aktualizowania użytkowników, co pozwala mu na uzyskanie uprawnień administratora poprzez edytowanie wartości `isadmin` w żądaniu.
- CVE-2023-37916Średnie
KubePi to otwartoźródłowy panel zarządzania Kubernetesem. Punkt końcowy /kubepi/api/v1/users/search?pageNum=1&&pageSize=10 ujawnia hasze haseł użytkowników, w tym administratorów, co może umożliwić atakującemu ich złamanie.
Oryginalny opis (angielski, źródło NVD)
KubePi is a Kubernetes multi-cluster management panel. In versions up to and including 2.0.0, cluster-scoped APIs do not consistently validate per-cluster access, allowing an authenticated user with cluster management permissions to operate on clusters outside the scope they were granted. Because the affected endpoints act on cluster-specific data without confirming that the requesting user is authorized for that particular cluster, a user assigned management rights over one cluster can, under certain role and cluster configurations, read or modify data in clusters they should not manage. This issue is fixed in version 2.0.1.