Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Redis ponownie znalazł się w centrum zainteresowania zespołów bezpieczeństwa po ujawnieniu nowych podatności pamięci, które w określonych warunkach mogą prowadzić do zdalnego wykonania kodu. Problem koncentruje się wokół mechanizmu odtwarzania danych, a konkretnie przetwarzania spreparowanych ładunków przy użyciu polecenia RESTORE.
W praktyce oznacza to, że atakujący posiadający uwierzytelniony dostęp do instancji Redis oraz odpowiednie uprawnienia ACL może doprowadzić do uszkodzenia pamięci procesu. Taki scenariusz otwiera drogę do dalszej eskalacji, włącznie z wykonaniem dowolnego kodu na serwerze.
W skrócie
Ujawnione w lipcu 2026 roku problemy obejmują co najmniej dwa odrębne łańcuchy prowadzące do RCE w Redis. Jeden z nich dotyczy Redis Streams i błędu use-after-free związanego ze współdzielonym obiektem NACK, a drugi obejmuje RedisBloom oraz loader TDigest, gdzie możliwy jest out-of-bounds write podczas ładowania spreparowanych danych.
- atak wymaga użycia polecenia
RESTORE, - w części scenariuszy potrzebne są także
EVAL,XGROUPlub obecność modułu RedisBloom, - producent opublikował poprawki dla kilku gałęzi wersji,
- środowiska zaktualizowane wcześniej mogą nadal wymagać kolejnej aktualizacji.
Kontekst / historia
To nie pierwszy przypadek, w którym Redis mierzy się z błędami prowadzącymi do uszkodzeń pamięci podczas deserializacji lub odtwarzania złożonych struktur danych. Już w maju 2026 roku opublikowano wcześniejsze poprawki bezpieczeństwa, jednak lipcowe ustalenia pokazały, że część środowisk nadal pozostawała narażona mimo niedawnych aktualizacji.
Istotnym aspektem tej sprawy jest fakt, że część wersji uznawanych za świeżo załatane wymagała kolejnej poprawki. Oznacza to, że organizacje nie powinny zakładać automatycznie, iż poprzedni cykl aktualizacji całkowicie usunął ryzyko związane z nowo opisanymi scenariuszami ataku.
Dodatkowe zainteresowanie wzbudziły informacje, że badacze mieli wykorzystać agentów AI do szybkiego identyfikowania błędów i generowania działających proof-of-conceptów. Niezależnie od roli automatyzacji, najważniejszy pozostaje potwierdzony fakt istnienia podatności oraz dostępności poprawek po stronie projektu Redis.
Analiza techniczna
Pierwszy łańcuch ataku dotyczy Redis Streams. Jego sednem jest nieprawidłowe współdzielenie własności obiektu pending-entry record, opisywanego wewnętrznie jako streamNACK. Spreparowany obiekt RDB może doprowadzić do sytuacji, w której dwóch konsumentów odwołuje się do tego samego wpisu NACK.
Gdy pierwszy konsument zostaje usunięty, obiekt zostaje zwolniony, ale drugi nadal przechowuje wskaźnik do już zwolnionej pamięci. Kolejna operacja na drugim konsumencie może skutkować ponownym zwolnieniem tego samego obszaru pamięci, co prowadzi do klasycznego scenariusza double-free i use-after-free.
Tego typu błąd nie zawsze oznacza natychmiastowe wykonanie kodu, ale daje atakującemu silny prymityw do dalszej eksploatacji. Przy odpowiednio przygotowanym układzie sterty możliwe staje się uzyskanie arbitralnego odczytu i zapisu pamięci procesu Redis, a następnie przejęcie przepływu wykonania.
Druga ścieżka prowadzi przez RedisBloom i komponent TDigest odpowiedzialny za ładowanie danych z formatu RDB. Problem wynika z niespójności między rozmiarem zaalokowanej pamięci a zaufaniem do osobnego pola pojemności kontrolowanego przez atakującego. W efekcie alokacja może nastąpić na podstawie jednej wartości, natomiast loader odczyta do bufora więcej elementów, niż faktycznie przewidziano.
Taki mechanizm tworzy warunki do zapisu poza granicami przydzielonej pamięci. W praktyce out-of-bounds write może zostać wykorzystany do budowy prymitywów odczytu i zapisu, wycieku adresów procesu oraz biblioteki libc, obejścia ASLR i finalnie do wykonania kodu.
Wspólnym mianownikiem obu ścieżek pozostaje polecenie RESTORE. Z punktu widzenia obrony jest to bardzo ważne, ponieważ ograniczenie tego uprawnienia znacząco redukuje powierzchnię ataku. Trzeba jednak podkreślić, że chodzi o atak uwierzytelniony, a więc szczególnie niebezpieczny w środowiskach, gdzie Redis jest osiągalny z segmentów aplikacyjnych, narzędzi administracyjnych, systemów CI/CD lub kont serwisowych.
Konsekwencje / ryzyko
Najpoważniejszą konsekwencją jest możliwość osiągnięcia RCE w procesie Redis. W zależności od modelu wdrożenia może to oznaczać przejęcie hosta, dostęp do danych znajdujących się w pamięci, manipulację rekordami bazy oraz wykorzystanie serwera jako punktu wyjścia do dalszych działań wewnątrz infrastruktury.
Ryzyko rośnie szczególnie wtedy, gdy Redis jest zbyt szeroko dostępny sieciowo lub gdy wiele kont posiada rozbudowane uprawnienia ACL. Dotyczy to także środowisk, w których udostępnione są komendy administracyjne i skryptowe, a organizacja zakłada błędnie, że niedawna aktualizacja automatycznie eliminuje wszystkie zagrożenia.
- wysokie ryzyko w środowiskach wielodostępowych i współdzielonych,
- podwyższone ryzyko przy aktywnym RedisBloom,
- istotne zagrożenie po przejęciu konta aplikacyjnego z prawem do
RESTORE, - możliwość wykorzystania Redis jako etapu ruchu bocznego.
Nawet jeśli podatność wymaga autoryzacji, kompromitacja jednego elementu aplikacyjnego może wystarczyć do wykorzystania luki w Redis jako kolejnego kroku w łańcuchu ataku. Publiczna dostępność proof-of-conceptów zwykle dodatkowo skraca czas potrzebny cyberprzestępcom na przygotowanie prób nadużyć.
Rekomendacje
Priorytetem powinno być szybkie przejście na poprawione wersje odpowiednie dla używanej gałęzi Redis. Organizacje powinny zweryfikować dokładny numer wersji wdrożonej w produkcji i porównać go z wydaniami bezpieczeństwa opublikowanymi po lipcowych ujawnieniach.
- zaktualizować Redis do wersji zawierających najnowsze poprawki bezpieczeństwa,
- odebrać uprawnienie
RESTOREwszystkim kontom, które nie potrzebują go operacyjnie, - ograniczyć lub wyłączyć dostęp do
EVALi komend administracyjnych dla kont aplikacyjnych, - sprawdzić, czy moduł RedisBloom jest rzeczywiście niezbędny,
- odseparować instancje Redis od sieci publicznych i nieufnych segmentów,
- wdrożyć zasadę najmniejszych uprawnień oraz rotację poświadczeń,
- monitorować nietypowe użycie
RESTORE,XGROUP,EVALi operacji ładowania RDB, - wykonać testy bezpieczeństwa po aktualizacji.
Z perspektywy SOC i IR warto rozszerzyć detekcje o anomalie związane z odtwarzaniem danych, restartami procesu Redis, błędami segmentacji oraz nagłymi awariami usługi. W przypadku podejrzenia wykorzystania podatności należy zabezpieczyć obrazy pamięci, przeanalizować historię poleceń administracyjnych oraz zweryfikować integralność hosta.
Podsumowanie
Lipcowe ujawnienie nowych błędów w Redis pokazuje, że usługi in-memory data store pozostają atrakcyjnym celem ataków, zwłaszcza gdy deserializacja i odtwarzanie złożonych struktur danych łączą się z błędami zarządzania pamięcią. Opisane luki prowadzą do use-after-free oraz out-of-bounds write, a w sprzyjających warunkach mogą zakończyć się pełnym RCE.
Dla organizacji kluczowe znaczenie mają szybka aktualizacja, przegląd rzeczywiście używanych uprawnień ACL oraz ograniczenie polecenia RESTORE. To kolejny sygnał, że nawet pozornie wewnętrzne komponenty middleware powinny być traktowane jako element infrastruktury wysokiego ryzyka.