CVE-2026-82441
KrytyczneCVSS 9.1Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 36 - wyżej niż 36% wszystkich znanych CVE
Streszczenie
Podatność w Apache Storm pozwala osobie przesyłającej topologię na usunięcie blobów należących do innych topologii poprzez podanie ich kluczy w listach `dependency_jars` i `dependency_artifacts`. Ponadto, brak walidacji może doprowadzić do sytuacji, w której Nimbus nie utrzyma przywództwa, co uniemożliwi działanie klastra.
Ocena ryzyka
Atakujący może celowo usunąć krytyczne pliki (np. stormjar.jar) innych topologii, powodując ich awarię. Dodatkowo, pojedynczy nieistniejący klucz może zablokować cały klaster, uniemożliwiając planowanie zadań, czyszczenie i przyjmowanie nowych zgłoszeń.
Rekomendacja
Należy natychmiast zaktualizować Apache Storm do wersji 3.1.0 lub nowszej. Jeśli aktualizacja nie jest możliwa, ogranicz możliwość przesyłania topologii tylko do zaufanych podmiotów i monitoruj logi Nimbusa pod kątem brakujących kluczy.
Inne podatności w Apache Storm
Zobacz wszystkie- CVE-2014-0115Wysokie
Podatność na przejście katalogu w narzędziu do przeglądania logów w Apache Storm 0.9.0.1 pozwala zdalnym atakującym na odczyt dowolnych plików poprzez wykorzystanie parametru pliku z sekwencją .. (kropka kropka).
- CVE-2026-82435Krytyczne
W Apache Storm przed wersją 3.1.0 istnieje podatność: dekoder Netty jest instalowany przed uwierzytelnianiem i przetwarza ramki bez weryfikacji, co pozwala nieuwierzytelnionemu atakującemu na alokację dużych buforów i potencjalne przeciążenie pamięci roboczych.
- CVE-2026-82431Krytyczne
W komponencie SimpleACLAuthorizer w Apache Storm autoryzacja kończyła się wcześnie, gdy lista nimbus.users była pusta, pomijając sprawdzanie nimbus.groups. W efekcie konfiguracja ograniczająca dostęp wyłącznie przez grupy nie działała i każdy uwierzytelniony użytkownik mógł wykonywać wszystkie operacje na poziomie użytkownika, w tym submitTopology, beginFileUpload i getNimbusConf. Problem naprawiono w wersji 3.1.0.
- CVE-2026-82439Krytyczne
Serwer DRPC w Apache Storm utrzymuje mapę nazw funkcji do kolejek żądań, a wpisy nigdy nie są usuwane. Atakujący może wysyłać dowolne nazwy funkcji bez uwierzytelnienia (ponieważ `drpc.authorizer` jest domyślnie wyłączony), co prowadzi do niekontrolowanego wzrostu pamięci i ostatecznie do wyczerpania sterty.
- CVE-2015-3188Krytyczne
Demon UI w Apache Storm w wersji 0.10.0 przed 0.10.0-beta1 umożliwia zdalnym atakującym wykonanie dowolnego kodu poprzez nieokreślone wektory.
- CVE-2026-82438Wysokie
W komponentach HTTP Apache Storm wykryto trzy niezależne mechanizmy, które pozwalały stronie internetowej z niezwiązanego originu odczytywać odpowiedzi serwowane uwierzytelnionemu użytkownikowi. Logviewer odbijał nagłówek Origin w Access-Control-Allow-Origin wraz z Access-Control-Allow-Credentials: true, wspólny filtr CORS był błędnie skonfigurowany (podano nazwę nagłówka odpowiedzi zamiast parametru inicjalizacyjnego, przez co kontener stosował własne domyślne ustawienia zezwalające na poświadczenia), a UI i Logviewer opakowywały odpowiedzi API w JSONP dla każdego żądania GET. W każdym przypadku strona odwiedzona przez uwierzytelnionego operatora może w jego imieniu odczytać dane klastra, topologii i logi.
- CVE-2026-82434Średnie
Gdy skonfigurowane jest uwierzytelnianie ZooKeeper, Storm celowo zachowuje storm.zookeeper.topology.auth.payload w konfiguracji topologii, a Nimbus udostępnia tę konfigurację każdemu użytkownikowi z uprawnieniami tylko do odczytu topologii. Użytkownik z uprawnieniami wyłącznie do przeglądania topologii otrzymuje poświadczenie ZooKeeper, które ma uprawnienia zapisu i pozwala fałszować lub usuwać stan topologii. Poświadczenie trafia także do logów (INFO w kliencie zgłoszeń, DEBUG w handlerach SASL), a poprawka w wersji 3.1.0 usuwa je z konfiguracji i logów.
- CVE-2026-82433Średnie
W Apache Storm przed wersją 3.1.0 funkcja getNimbusConf zwraca pełną konfigurację bez maskowania poufnych danych, a endpoint UI /api/v1/cluster/configuration nie wymaga odpowiedniej autoryzacji, co może ujawnić hasła i klucze.
- CVE-2026-82432Wysokie
W Apache Storm przed wersją 3.1.0 operacja rebalance nie ponownie weryfikuje mapy blobstore względem uprawnień, a także listBlobs nie sprawdza autoryzacji, co pozwala uprawnionemu użytkownikowi na dostęp do niedozwolonych blobów i ujawnienie metadanych.
- CVE-2026-82430Wysokie
W podatności CVE-2026-82430 w Apache Storm program setuid-root `worker-launcher` najpierw zmienia właściciela całego katalogu workera na niezaufanego użytkownika topologii, a dopiero potem odczytuje plik poleceń zapisany w tym katalogu. Plik jest otwierany bez flagi `O_NOFOLLOW` i bez ponownej weryfikacji właściciela, więc w oknie między zmianą właściciela a odczytem najemca może podmienić jego zawartość. W ścieżce Docker podmienione polecenie jest wykonywane z rzeczywistym uid 0, a w ścieżce OCI możliwe jest bind-mountowanie dowolnych ścieżek hosta z prawem zapisu.
Oryginalny opis (angielski, źródło NVD)
Description A submitted topology carries two lists of blobstore keys, `dependency_jars` and `dependency_artifacts`, which the client fills in after uploading the corresponding blobs. Nimbus performed no validation of their contents on the submission path, yet acts on them in two places. During cleanup of a finished topology, Nimbus deletes the keys named in those lists, and the deletion is performed as the Nimbus subject, for which the blobstore short-circuits its ACL check. A submitter who listed a key belonging to another topology, such as its `-stormjar.jar`, could therefore cause that blob to be deleted when their own topology was cleaned up. Separately, on acquiring leadership a Nimbus compares the dependency keys of all active topologies against the blobstore contents and surrenders leadership if any is missing. A single key that does not exist, on a single active topology, therefore causes every Nimbus to acquire leadership, surrender it and requeue indefinitely, leaving the cluster without a leader and unable to schedule, clean up or accept submissions. Mitigation Upgrade to 3.1.0, where a submission is refused unless every entry in both lists is a dependency blob key and exists in the blobstore. Note that this validates new submissions only; a topology stored by an affected version with an invalid list is unaffected by the upgrade. An operator whose cluster is failing to retain a leader should inspect the Nimbus log for the dependency keys reported as missing and remove or resubmit the topology naming them. Users who cannot upgrade immediately should restrict topology submission to trusted principals. Credit This issue was discovered by rzo1 while investigating an unrelated blobstore defect.