CVE-2026-61672

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ę.

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.

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.

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.

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.

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.

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.