CVE-2026-82428
WysokieCVSS 8.8Streszczenie
Podatność w Apache Storm dotyczy funkcji `storm jar --artifacts`, która przechowuje artefakty zależności pod kluczem opartym wyłącznie na współrzędnych Maven, co czyni go przewidywalnym i wspólnym dla wszystkich użytkowników. Jeśli blob już istnieje, jest on cicho ponownie wykorzystywany bez weryfikacji właściciela, co pozwala atakującemu na podstawienie własnych danych, prowadząc do wykonania kodu w topologii innego użytkownika.
Ocena ryzyka
Ryzyko polega na możliwości zdalnego wykonania kodu w kontekście innej dzierżawy (tenanta) na współdzielonym klastrze Storm, co może skutkować przejęciem danych lub eskalacją uprawnień.
Rekomendacja
Należy natychmiast uaktualnić zarówno klienta, jak i klaster do wersji 3.1.0 lub nowszej, gdzie generowany jest unikalny UUID dla każdego artefaktu. Przed aktualizacją zaleca się audyt istniejących blobów o nazwie `dep-` pod kątem nieoczekiwanych właścicieli, a w przypadku braku możliwości aktualizacji należy unikać korzystania z `--artifacts` w środowiskach wielodostępnych i dystrybuować zależności w jar topologii.
Inne podatności w Apache Storm
Zobacz wszystkie- 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-82427Wysokie
Podatność w Apache Storm umożliwia atakującemu wykorzystanie ścieżek względnych (../) w mapie `topology.blobstore.map` do wymuszenia usunięcia i utworzenia dowiązania symbolicznego w dowolnym miejscu systemu plików, działając jako użytkownik nadzorcy (supervisor). Może to prowadzić do rekurencyjnego usuwania danych oraz podmiany dowiązań, co przy uruchamianiu workerów pozwala na wykonanie kodu atakującego w kontekście innego użytkownika systemu, łamiąc izolację między tenantami.
- CVE-2026-82426Średnie
Podatność w Apache Storm pozwala uwierzytelnionemu użytkownikowi z prawami do przesyłania topologii na wskazanie dowolnej ścieżki pliku jako jar topologii, zamiast wymaganego pliku przesłanego przez klienta. Nimbus otwiera tę ścieżkę bez weryfikacji, czy plik został faktycznie przesłany, co umożliwia odczyt plików dostępnych dla użytkownika demona Nimbus.
- CVE-2026-84179Średnie
Podatność w Apache Storm pozwala na odczyt danych uwierzytelniających (np. storm.zookeeper.auth.payload, hasła do keystore/truststore) przez nieautoryzowanych użytkowników korzystających z API topologii, ponieważ konfiguracja Nimbusa jest łączona z konfiguracją topologii i zwracana bez maskowania.
- 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-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.
Oryginalny opis (angielski, źródło NVD)
Description Dependency artifacts uploaded with `storm jar --artifacts` were stored under a blob key derived only from the Maven coordinate, for example `dep---.jar`. The key was therefore identical for every user of the cluster and predictable in advance. When the blob already existed, the uploader caught `KeyAlreadyExistsException` and silently reused it, with no check that the existing blob's content or owner matched the artifact the submitter had resolved. A user who uploaded a blob under such a key first therefore controlled the bytes that every later submitter of the same coordinate would receive on the worker classpath, resulting in code execution inside another tenant's topology. This affects deployments where more than one principal may create blobs and where the `--artifacts` dependency feature is used. Mitigation Upgrade to 3.1.0, where each uploaded artifact receives a key carrying a freshly generated UUID and a pre-existing blob is no longer silently reused. Note that the corrected key generation is on the SUBMITTING CLIENT, so upgrading the cluster alone does not close this; every client that runs `storm jar --artifacts` must also be upgraded. Operators should audit existing `dep-` blobs for unexpected owners before upgrading. Users who cannot upgrade immediately should avoid the `--artifacts` mechanism in multi-tenant clusters and distribute dependencies inside the topology jar instead. Credit The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm.