Dwa commity go zasadziły. Dwa lata go ukrywały. Code review nigdy go nie znalazł — znalazło AI.

Jeśli używasz Redisa — zaktualizuj do załatanej wersji swojej serii: 7.2.14, 7.4.9, 8.2.6, 8.4.3 lub 8.6.3 (wszystkie z 5 maja). Aktualizacje pomocnicze w obrębie serii są zaprojektowane jako drop-in. Jeśli nie możesz załatać od razu: trzymaj Redisa poza publicznym internetem i za TLS, zaostrz listy ACL tak, by żadna rola nie łączyła @admin, CONFIG i @scriptingnaraz, i odetnij @scripting, jeśli nie używasz Lua — to zabija pierwszy etap exploita. Redis Cloud jest już załatany; usługi zarządzane łatają według własnych harmonogramów.

Redis załatał use-after-free w kodzie obsługi zablokowanych klientów, który pozwala uwierzytelnionemu użytkownikowi wykonać dowolne polecenia systemu operacyjnego na maszynie hostującej bazę. Błąd, oznaczony jako CVE-2026-23479, został wprowadzony w Redis 7.2.0 i przetrwał w każdej stabilnej gałęzi aż do poprawek z 5 maja — niezauważony przez ponad dwa lata. NVD ocenia go na 8.8 w skali CVSS 3.1.

Ale najważniejsze nie jest samo RCE. Najważniejsze jest to, kto je znalazł — i czego to dowodzi o serii, którą opisujemy od miesięcy.

Błąd zgłosił zespół Team Xint Code. Theori opisuje Xint Code jako autonomiczne narzędzie bezpieczeństwa oparte na AI, zbudowane do polowania na błędy w dużych bazach kodu. Zademonstrowano działające RCE na ZeroDay.Cloud 2025 — konkursie hakerskim Wiz w Londynie w grudniu. Narzędzie AI znalazło dwuletnią lukę w jednej z najczęściej wdrażanych baz danych na świecie, której ludzki code review nie wychwycił przez dwie dekady przeglądów.

Jak powstał błąd, którego nikt nie zauważył

To jest najciekawsza część — bo pokazuje dokładnie ten typ błędu, który AI widzi, a człowiek przegapia.

Według analizy Wiz, błąd powstał z dwóch commitów. Refaktoryzacja ze stycznia 2023 dodała niesprawdzane wywołanie. Zmiana z marca 2023 dodała kolejny dostęp do struktury klienta po tym wywołaniu. Żaden z tych commitów nie był groźny osobno. Dopiero razem dotarły do wersji ogólnodostępnej w 7.2.0 i przetrwały wiele rund przeglądu bezpieczeństwa.

Mechanizm: funkcja unblockClientOnKey() wywołuje processCommandAndResetClient(), a potem dalej używa tego samego wskaźnika do klienta. Problem w tym, że ta funkcja może zwolnić klienta jako efekt uboczny — i jej własny komentarz w nagłówku to mówi. Wywołujący ignoruje zwracaną wartość i czyta zwolnioną strukturę mimo to. Use-after-free, CWE-416.

Zwróć uwagę na szczegół: komentarz w kodzie wprost ostrzegał, że funkcja może zwolnić klienta. Człowiek czytający refaktoryzację w styczniu 2023 nie połączył tego ostrzeżenia z konsekwencją. Człowiek czytający zmianę w marcu 2023 nie zobaczył, że dokłada dostęp do struktury, która może już nie istnieć. Dwa osobne przeglądy, dwa osobne momenty, w których trzeba było zobaczyć interakcję między oddalonymi fragmentami kodu — i ludzki przegląd jej nie zobaczył.

To jest dokładnie ta klasa, którą opisywaliśmy przy raporcie GTIG: błędy semantyczne, wynikające z interakcji oddalonych części kodu, niewidoczne dla skanerów strukturalnych i trudne do wychwycenia dla człowieka, który czyta jeden plik naraz. AI czyta całą bazę kodu jednocześnie i widzi, że ostrzeżenie z nagłówka jednej funkcji nie zostało uszanowane przez wywołującego dwa pliki dalej.

Pętla, którą domykamy trzeci raz w tym tygodniu

To jest trzeci raz w ciągu kilku dni, gdy opisujemy AI znajdujące lukę, której ludzie nie znaleźli.

HTTP/2 Bomb znalazł Codex OpenAI — i jego łatka stała się mapą dla AI do znalezienia tych samych błędów w IIS, Envoy i Pingora. Glasswing znalazł ponad 10 000 podatności w miesiąc, w tym osiemnastoletni błąd w nginx. Teraz Xint Code znajduje dwuletni use-after-free w Redisie, na konkursie hakerskim.

W Radarze #2 postawiliśmy tezę, że wąskim gardłem bezpieczeństwa przestało być znajdowanie podatności — stało się nim ich naprawianie. CVE-2026-23479 jest kolejnym punktem danych w tym obrazie. Redis to jedna z najczęściej wdrażanych baz danych na świecie, obecna — według analizy Wiz — w zdecydowanej większości środowisk chmurowych, przy czym większość instancji działa bez hasła. Błąd siedział tam dwa lata. Znalazło go nie dwie dekady przeglądów społeczności, ale jedno autonomiczne narzędzie AI w trakcie zawodów.

To jest dobra wiadomość i niepokojąca naraz — ta sama dwoistość, którą opisujemy od maja. Dobra: AI po stronie obrońców znajduje stare, głęboko ukryte błędy, zanim zrobią to atakujący. Niepokojąca: skoro narzędzie AI znalazło to w trakcie konkursu, narzędzia AI po drugiej stronie znajdą podobne błędy w kodzie, który dziś uważamy za sprawdzony. Pełny łańcuch techniczny jest teraz publiczny, co zwiększa ryzyko wtórnej eksploatacji.

Dlaczego chmura czyni to gorszym

Exploit wymaga uwierzytelnionej sesji — co brzmi jak ograniczenie. Ale w domyślnym wdrożeniu Redisa to ograniczenie jest iluzoryczne.

Pełny łańcuch potrzebuje sesji z uprawnieniami CONFIG SET, EVAL, poleceń strumieni i podstawowych SET/GET — co mapuje się na kategorie ACL @admin, @scripting, @stream i @read/@write. Domyślny użytkownik Redisa ma je wszystkie. A w większości wdrożeń te uprawnienia są zgrupowane w jedną współdzieloną rolę aplikacji lub operatora.

Innymi słowy: „wymaga uwierzytelnienia" w praktyce oznacza „wymaga dostępu, który domyślny użytkownik już ma". To jest ten sam wzorzec, który opisywaliśmy przy Apex One — restrykcyjne warunki wstępne, które w realnym wdrożeniu są domyślnie spełnione. Większość instancji Redisa w chmurze działa bez hasła, więc bariera uwierzytelnienia, która miałaby chronić, często po prostu nie istnieje.

Oficjalny obraz Docker Redisa pogarsza ostatni etap — dostarczany jest z tylko częściowym RELRO, zostawiając tablicę GOT zapisywalną w trakcie działania. ASLR i PIE tu nie pomagają, bo zapis jest względny do globalnego symbolu, którego przesunięcie jest ustalone na etapie budowania.

Nie pierwszy raz w tym samym miejscu

CVE-2026-23479 było jednym z pięciu błędów klasy RCE w Redisie ujawnionych w zeszłym miesiącu. I podąża za zeszłoroczną luką RediShell — również uwierzytelnionym use-after-free związanym ze skryptami Lua.

To jest wzorzec, który opisywaliśmy przy serii kernela Linuksa i przy HTTP/2: gdy jeden obszar kodu trafia pod lupę, kolejne błędy tej samej klasy zaczynają się sypać. Skrypty Lua w Redisie były już źródłem RediShell; teraz są pierwszym etapem łańcucha CVE-2026-23479. Pięć RCE w miesiąc w jednej bazie danych to nie pech — to skutek tego, że ktoś (tym razem AI) zaczął patrzeć systematycznie.

Co zrobić

Zaktualizuj do załatanej wersji swojej serii: 7.2.14, 7.4.9, 8.2.6, 8.4.3 lub 8.6.3. Aktualizacje pomocnicze w obrębie serii są drop-in.

Jeśli nie możesz załatać od razu: trzymaj Redisa poza publicznym internetem i za TLS. Zaostrz ACL tak, by żadna rola nie łączyła @admin, CONFIG i @scripting naraz — odmowa CONFIG łamie ten konkretny łańcuch, choć nie usuwa samego use-after-free. Odetnij @scripting, jeśli nie używasz Lua — to zabija etap pierwszy, czyli wyciek adresu sterty.

Priorytetyzuj instancje wystawione na internet, współdzielone poświadczenia aplikacji i każdą rolę łączącą CONFIG, skrypty i dostęp do strumieni. Przy okazji obróć szeroko współdzielone poświadczenia Redisa.

Redis nie ma dowodów na eksploatację we własnych ani klienckich środowiskach, i na moment publikacji nie pojawiły się publiczne raporty o atakach w praktyce. Ale pełny łańcuch techniczny jest już publiczny.

Źródła

The Hacker News — omówienie z pełnym łańcuchem exploita i kontekstem Xint Code: https://thehackernews.com/2026/06/autonomous-ai-tool-finds-2-year-old-rce.html

Redis — oficjalne security advisory dla pięciu CVE: https://redis.io/blog/security-advisory-cve202623479-cve202625243-cve-2026-25588-cve202625589-cve-2026-23631/

ZeroDay.Cloud / Wiz — głęboka analiza techniczna CVE-2026-23479: https://www.zeroday.cloud/blog/redis-cve-2026-23479-deep-dive

Theori — opis autonomicznego narzędzia Xint Code: https://theori.io/blog/announcing-xint-code