CVE-2026-61795
ŚrednieCVSS 6.8Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 46 - wyżej niż 46% wszystkich znanych CVE
Streszczenie
Capsule od wersji 0.13.0 do 0.13.7 zawiera podatność w webhooku walidacji Tenant, gdzie parametry new i old są odwrócone, co powoduje walidację poprzedniego wyrażenia AllowedHostnames.Regex zamiast nowego. Administrator klastra może zapisać nieprawidłowe wyrażenie, co później blokuje operacje Ingress dla dzierżawcy. Problem został naprawiony w wersji 0.13.7.
Ocena ryzyka
Nieprawidłowa konfiguracja może prowadzić do blokady operacji Ingress, co może zakłócić działanie aplikacji w klastrze Kubernetes.
Rekomendacja
Zaktualizuj Capsule do wersji 0.13.7 lub nowszej. Sprawdź i napraw istniejące konfiguracje Tenant.
Inne podatności w Capsule
Zobacz wszystkie- CVE-2026-22872Krytyczne
Podatność w Capsule, frameworku do wielodzierżawności i polityk dla Kubernetes. Kontroler Capsule działa z uprawnieniami cluster-admin. Przetwarzanie TenantResource RawItems nieprawidłowo obsługuje zasoby na poziomie klastra, co pozwala administratorom dzierżaw na tworzenie zasobów klastrowych (np. ClusterRole, ValidatingWebhookConfiguration) z podniesionymi uprawnieniami, prowadząc do eskalacji uprawnień między dzierżawami i ataków na poziomie klastra. Wersja 0.13.0 zawiera poprawkę.
- CVE-2026-61794Średnie
Capsule od wersji 0.13.0 do 0.13.7 zawiera podatność w walidacji aktualizacji Tenant, gdzie wyrażenie ForbiddenLabels.Regex jest kompilowane zarówno dla kontroli etykiet, jak i adnotacji, zamiast walidować ForbiddenAnnotations.Regex. Administrator może zapisać nieprawidłowe wyrażenie, co później powoduje panikę regexp.MustCompile podczas walidacji metadanych i blokuje operacje namespace. Problem został naprawiony w wersji 0.13.7.
- CVE-2026-61672Wysokie
W frameworku Capsule przed wersją 0.13.7 funkcja ForbiddenListSpec.ExactMatch w pkg/api/forbidden_list.go sortuje zabronione klucze metadanych bez uwzględniania wielkości liter, a następnie używa sort.SearchStrings, które zakłada sortowanie bajtowe. Gdy lista zabronionych miesza wielkie i małe litery, wyszukiwanie binarne może zwrócić fałsz dla obecnego klucza. Uwierzytelniony właściciel tenanta może ominąć ograniczenia metadanych przestrzeni nazw, Service lub delegowanych węzłów. Podatność jest naprawiona w wersji 0.13.7.
- CVE-2026-55636Średnie
Capsule od wersji 0.13.0 do 0.13.6 ma podatność w konfiguracji webhooka walidującego, gdzie użyto nazwy namespace/finalize zamiast poprawnej nazwy zasobu Kubernetes namespaces/finalize. Użytkownik z uprawnieniami RBAC do namespaces/finalize może wysłać żądanie PUT do /api/v1/namespaces/{namespace}/finalize, a reguła pojedyncza nie pasuje do zasobu mnogiego, więc webhook nie jest wywoływany i użytkownik może zmienić etykietę tenant namespace.
- CVE-2026-65835Średnie
Capsule od 0.13.0 do 0.13.8 (po niepełnej łatce CVE-2026-22872) nie stosował zabezpieczeń przed tworzeniem zasobów klastrowych przez Tenant Owner. Tenant Owner mógł tworzyć zasoby takie jak ClusterRole lub ValidatingWebhookConfiguration poprzez klienta kontrolera cluster-admin.
- CVE-2026-65834Średnie
Capsule przed 0.13.8 nie walidował wyrażeń regularnych w konfiguracji CapsuleConfiguration dla ForbiddenLabels i ForbiddenAnnotations. Administrator klastra mógł przechowywać nieprawidłowe regex, które powodowały awarię webhooka węzła przy tworzeniu, aktualizacji lub łataniu węzła.
- CVE-2026-30963Niskie
W frameworku Capsule dla Kubernetes przed wersją 0.13.0 wykryto podatność umożliwiającą przejęcie przestrzeni nazw (namespace hijacking) poprzez operacje na subresources namespace/finalize i namespace/status. Webhook walidujący nie definiuje reguł przechwytywania dla tych subresources, co pozwala administratorowi dzierżawcy na modyfikację metadanych przestrzeni nazw.
Oryginalny opis (angielski, źródło NVD)
Capsule is a multi-tenancy and policy-based framework for Kubernetes. From 0.13.0 until 0.13.7, hostnameRegexHandler.OnUpdate in internal/webhook/tenant/validation/hostname_regex.go reverses the new and old Tenant parameters and validates the previous AllowedHostnames.Regex instead of the submitted value. A cluster administrator can therefore store a malformed AllowedHostnames.Regex after the webhook accepts the update based on stale valid state. Subsequent Ingress creation or update reaches validate_hostnames.go, which evaluates the malformed pattern, ignores the regular-expression error, and treats every hostname as unmatched, blocking Ingress operations for the affected tenant until an administrator repairs the Tenant configuration. This issue is fixed in version 0.13.7.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS

