Wprowadzenie do problemu / definicja
Dell udostępnił poprawki bezpieczeństwa dla pakietu Container Storage Modules (CSM), który odpowiada za integrację środowisk Kubernetes z macierzami i usługami pamięci masowej producenta. Ujawnione podatności dotyczą przede wszystkim mechanizmów autoryzacji oraz operatora CSM, czyli komponentów działających blisko warstwy uprzywilejowanej i mających realny wpływ na bezpieczeństwo całego klastra.
Skuteczne wykorzystanie tych luk może prowadzić do obejścia uwierzytelniania, eskalacji uprawnień, fałszowania tokenów oraz uzyskania dostępu root do węzłów Kubernetes. To sprawia, że incydent wykracza poza typowy problem aplikacyjny i dotyczy bezpośrednio integralności infrastruktury cloud-native.
W skrócie
- Podatności obejmują komponenty CSM Authorization i operator CSM.
- Najpoważniejsze luki umożliwiają nieuwierzytelniony dostęp administracyjny oraz obejście kontroli dostępu.
- Część błędów pozwala generować poprawne tokeny administracyjne z powodu statycznych sekretów.
- Możliwa jest eskalacja uprawnień aż do poziomu root na węzłach klastra.
- Problem dotyczy wersji starszych niż 1.17.0, a poprawki uwzględniono w wydaniu 1.18.0.
Kontekst / historia
Dell Container Storage Modules to zestaw komponentów używanych do połączenia warstwy orkiestracji kontenerów z zapleczem storage. Obejmuje to między innymi sterowniki, moduły autoryzacji i operatorów odpowiedzialnych za wdrożenie oraz utrzymanie integracji w klastrach Kubernetes.
Z perspektywy bezpieczeństwa jest to szczególnie wrażliwa część ekosystemu, ponieważ oprogramowanie działa zwykle z wysokimi uprawnieniami i ma dostęp do konfiguracji, sekretów, polityk RBAC oraz zasobów pamięci masowej. Błędy w tej warstwie mogą więc otworzyć drogę nie tylko do przejęcia aplikacji kontenerowych, ale również do naruszenia kontroli nad wolumenami, danymi i samymi hostami klastra.
W opublikowanym biuletynie producent wskazał zarówno luki w komponentach własnych, jak i problemy powiązane z otoczeniem wdrożeniowym. Największe znaczenie operacyjne mają jednak podatności w modułach odpowiadających za uwierzytelnianie, autoryzację i wykonywanie operacji uprzywilejowanych.
Analiza techniczna
Do najgroźniejszych błędów należą CVE-2026-63688 oraz CVE-2026-63692, obie ocenione bardzo wysoko i mogące prowadzić do pełnego obejścia zabezpieczeń. Pierwsza luka wynika z braku wymaganego uwierzytelnienia dla krytycznej funkcji w serwerze gRPC komponentu csm-authorization-storage. W praktyce zdalny atakujący może uzyskać nieautoryzowany dostęp do poświadczeń administracyjnych backendu storage dla zarejestrowanych macierzy.
Druga z kluczowych podatności dotyczy proxy autoryzacyjnego i usługi tenant service. Jej wykorzystanie pozwala ominąć kontrolę dostępu i przejąć uprawnienia administracyjne, co ma szczególne znaczenie w środowiskach wielodostępnych, gdzie granice między tenantami powinny być ściśle egzekwowane.
Istotnym zagrożeniem jest również CVE-2026-67269 w operatorze CSM. Problem wynika z błędnego zarządzania uprawnieniami w reconcilerze zasobu ContainerStorageModule Custom Resource. W efekcie użytkownik z niskimi uprawnieniami może doprowadzić do eskalacji uprawnień i uzyskać dostęp root do węzłów klastra, co czyni tę podatność wyjątkowo niebezpieczną z punktu widzenia architektury Kubernetes.
Kolejna grupa błędów dotyczy sekretów i tokenów. CVE-2026-54472 opisuje użycie zakodowanych na stałe poświadczeń w module CSM Authorization, co umożliwia tworzenie kryptograficznie poprawnych tokenów administracyjnych. Z kolei CVE-2026-61421 odnosi się do zakodowanego na stałe klucza kryptograficznego w komponencie JWT uwierzytelniania karavi-authorization. Jeżeli organizacja wdrożyła ten komponent zgodnie z wcześniejszymi zaleceniami i nie przeprowadziła rotacji sekretów, napastnik może generować tokeny i podszywać się pod użytkowników uprzywilejowanych.
Na uwagę zasługuje także CVE-2026-67273, związana z niewłaściwą neutralizacją danych wejściowych w silniku szablonów. Luka może prowadzić do eskalacji uprawnień, ujawnienia danych wrażliwych oraz nieautoryzowanej modyfikacji RBAC. W praktyce oznacza to możliwość odczytu sekretów Kubernetes i tworzenia zasobów o zasięgu całego klastra z pominięciem założonych ograniczeń.
Cały zestaw błędów układa się w klasyczny łańcuch kompromitacji środowiska cloud-native: od obejścia uwierzytelniania, przez fałszowanie tożsamości i tokenów, po manipulację RBAC, przejęcie sekretów i finalnie dostęp root do węzłów. Ponieważ luki występują w warstwie integrującej Kubernetes z pamięcią masową, skutki mogą objąć zarówno aplikacje, jak i same dane oraz polityki dostępu do wolumenów.
Konsekwencje / ryzyko
Ryzyko dla organizacji korzystających z Dell CSM należy ocenić jako bardzo wysokie, zwłaszcza w środowiskach produkcyjnych, współdzielonych i silnie zautomatyzowanych. Atakujący może uzyskać szeroki zakres możliwości operacyjnych, które bezpośrednio wpływają na poufność, integralność i dostępność usług.
- uzyskanie administracyjnego dostępu do usług autoryzacyjnych,
- przejęcie poświadczeń backendów storage,
- modyfikacja polityk dostępu między tenantami,
- odczyt sekretów Kubernetes,
- tworzenie lub zmiana zasobów RBAC o zasięgu całego klastra,
- przejęcie węzłów z uprawnieniami root.
W praktyce może to oznaczać trwałe utrzymanie dostępu w środowisku, sabotaż konfiguracji storage, naruszenie separacji między zespołami lub klientami, a także ryzyko utraty integralności wolumenów i niedostępności usług krytycznych. W organizacjach regulowanych konsekwencją może być dodatkowo incydent naruszenia danych i konieczność przeprowadzenia formalnych działań po stronie zgodności.
Rekomendacje
Najważniejszym krokiem jest szybkie zidentyfikowanie wszystkich wdrożeń Dell Container Storage Modules oraz weryfikacja wersji używanych komponentów. Organizacje powinny przeprowadzić aktualizację do wersji 1.18.0 i wycofać starsze wydania, szczególnie tam, gdzie aktywnie używany jest moduł CSM Authorization lub operator CSM.
Sama aktualizacja nie musi jednak wystarczyć. Konieczna jest również rotacja wszystkich sekretów JWT oraz innych kluczy wykorzystywanych przez komponenty autoryzacyjne. Jest to szczególnie ważne w środowiskach historycznie opartych na karavi-authorization lub wdrażanych na podstawie wcześniejszej dokumentacji, w których sekret mógł być znany publicznie albo zostać ujawniony.
- ograniczyć dostęp sieciowy do usług gRPC i proxy CSM wyłącznie do zaufanych segmentów,
- przejrzeć i zaostrzyć polityki RBAC dla operatorów, kontrolerów i kont serwisowych,
- monitorować tworzenie zasobów ContainerStorageModule oraz zmiany cluster-scoped RBAC,
- audytować dostęp do sekretów Kubernetes i logować nietypowe operacje administracyjne,
- zweryfikować, czy nie utworzono nieautoryzowanych tenantów, ról lub tokenów,
- przeprowadzić retrospektywną analizę logów pod kątem prób nadużycia usług autoryzacyjnych.
W środowiskach o podwyższonych wymaganiach bezpieczeństwa uzasadnione może być czasowe odseparowanie podatnych komponentów od sieci do momentu zakończenia pełnej remediacji i potwierdzenia, że nie doszło do wcześniejszej kompromitacji.
Podsumowanie
Krytyczne luki w Dell Container Storage Modules pokazują, jak duże ryzyko niosą błędy w komponentach łączących Kubernetes z infrastrukturą storage. Ujawnione podatności obejmują brak uwierzytelniania, błędy w kontroli dostępu, statyczne sekrety oraz możliwość manipulacji RBAC, a ich łączny wpływ może prowadzić do pełnego przejęcia środowiska.
Dla zespołów bezpieczeństwa i administratorów oznacza to konieczność pilnej aktualizacji, rotacji kluczy i sekretów oraz dokładnego przeglądu integralności klastra po wdrożeniu poprawek. Szczególną uwagę należy poświęcić oznakom eskalacji uprawnień, nieautoryzowanym tokenom i zmianom w konfiguracji storage oraz kontach uprzywilejowanych.