Redis heeft een use-after-free patch in de blocking-client-code aangebracht waarmee een geverifieerde gebruiker willekeurige OS-opdrachten kan uitvoeren op de machine die als host fungeert voor de database. De fout werd ontdekt door een autonome AI-tool die is gebouwd om bugs in grote codebases op te sporen.
De fout, bijgehouden als CVE-2026-23479, werd geïntroduceerd in Redis 7.2.0 en bleef in elke stabiele branch tot de fixes van 5 mei, meer dan twee jaar onopgemerkt. NVD beoordeelt het met een 8,8 onder CVSS 3.1; Redis vermeldt het als 7.7 onder CVSS 4.0. Het werd gerapporteerd door Team Xint Code en een volledig technisch artikel is nu openbaar.
De cloudvoetafdruk maakt dit nog erger. De analyse van Wiz, gepubliceerd met de exploitbeschrijving, plaatst Redis in een grote meerderheid van cloudomgevingen, waarbij de meeste van die instanties zonder wachtwoord draaien. De exploit heeft een geverifieerde sessie nodig, maar bij een standaardimplementatie beschikt de standaardgebruiker al over alle rechten die de keten vereist.
De fout leeft erin deblokkeerClientOnKey() in src/blocked.c, dat wordt geactiveerd wanneer een sleutelgebeurtenis een geblokkeerde opdracht activeert. De functie verzendt de opdracht in de wachtrij door procesCommandAndResetClient()en blijft vervolgens dezelfde clientaanwijzer gebruiken. Het probleem: die functie kan de client als bijwerking bevrijden, en zijn eigen headercommentaar zegt dat ook. De beller negeert de retourwaarde en leest toch de vrijgegeven structuur, een use-after-free (CWE-416).
Volgens de analyse van Wiz waren er twee commits nodig om de bug te maken. Een refactor uit januari 2023 (PR #11012) heeft de niet-gecontroleerde oproep toegevoegd. Een wijziging uit maart 2023 (PR #11568) heeft daarna meer clienttoegang toegevoegd. Geen van beide was alleen gevaarlijk. Samen bereikten ze algemene beschikbaarheid in 7.2.0 en overleefden ze meerdere rondes van beveiligingsbeoordeling.
De keten begint met het lekken van een heapadres. Van daaruit bevrijdt het een client en plaatst het een nep-client in hetzelfde geheugen, waarna Redis’ eigen geheugenaccounting tegen zichzelf wordt gebruikt om een functieaanwijzer te overschrijven.
De gepubliceerde versie verloopt in drie fasen.
- Ten eerste lekt een Lua-script van één regel (EVAL “return tostring(redis.call)” 0) een heap-pointer.
- Ten tweede bewaakt de aanvaller de geheugenlimieten van de client, parkeert een opgeblazen client in een stream, laat vervolgens de limieten vallen en maakt hem wakker. Redis bevrijdt de geblokkeerde client halverwege het gesprek, en een pijplijn-SET claimt onmiddellijk het vrijgekomen slot terug met een nep-clientstructuur.
- Ten derde voert de routinematige geheugenaccounting van Redis in updateClientMemoryUsage() een verlaging buiten het bereik uit met behulp van door de aanvaller bestuurde velden, gericht op de Global Offset Table om strcasecmp() opnieuw te richten op system(). De volgende opdracht die Redis parseert, wordt uitgevoerd als een shell-opdracht.
De officiële Redis Docker-image maakt de laatste stap eenvoudiger. Het wordt geleverd met slechts een gedeeltelijke RELRO, waardoor de GOT tijdens runtime beschrijfbaar blijft. ASLR en PIE helpen hier niet, omdat het schrijven relatief is ten opzichte van een global waarvan de offset tijdens het bouwen wordt vastgesteld.
De volledige keten heeft een geverifieerde sessie nodig met CONFIG SET, EVAL, stream-opdrachten (XREAD/XADD) en standaard SET/GET, die is toegewezen aan de categorieën @admin, @scripting, @stream en @read/@write ACL.
De standaardgebruiker heeft ze allemaal, en in de meeste implementaties zijn deze bevoegdheden gegroepeerd in één gedeelde applicatie- of operatorrol. Het weigeren van CONFIG verbreekt deze specifieke keten volledig, maar niet de onderliggende use-after-free.
Team Xint Code demonstreerde de werkende RCE tijdens ZeroDay.Cloud 2025, de hackwedstrijd van Wiz in Londen afgelopen december. Theori beschrijft Xint-code als een autonome AI-beveiligingstool die is gebouwd om op bugs in grote codebases te jagen.
Redis zei dat het geen bewijs had van uitbuiting in zijn eigen omgeving of in die van klanten, en dat er vanaf de publicatie geen openbare rapporten zijn opgedoken. De volledige technische keten is nu openbaar, waardoor het risico op vervolguitbuiting groter wordt.
Upgrade naar de gepatchte minor voor uw serie: 7.2.14, 7.4.9, 8.2.6, 8.4.3 of 8.6.3, allemaal uitgebracht op 5 mei. Kleine upgrades binnen een serie zijn bedoeld als drop-in. Beheerde Redis-services patchen volgens hun eigen schema’s, en Redis zegt dat Redis Cloud al klaar is.
| Tak | Aangetast | Vast |
|---|---|---|
| 7.2.x | 7.2.0 tot 7.2.13 | 7.2.14 |
| 7.4.x | 7.4.0 tot 7.4.8 | 7.4.9 |
| 8.2.x | 8.2.0 tot 8.2.5 | 8.2.6 |
| 8.4.x | 8.4.0 tot 8.4.2 | 8.4.3 |
| 8.6.x | 8.6.0 tot 8.6.2 | 8.6.3 |
Als je nog niet kunt patchen: houd Redis buiten het publieke internet en achter TLS, verscherp de ACL’s zodat geen enkele rol @admin, CONFIG en @scripting bij elkaar houdt, en weiger @scripting als je Lua niet gebruikt, waardoor het Stage 1-lek wordt opgeheven.
Geef prioriteit aan op het internet blootgestelde instances, gedeelde applicatiereferenties en elke rol die CONFIG, scripting en streamtoegang combineert. Roteer alle breed gedeelde Redis-inloggegevens terwijl u bezig bent.
CVE-2026-23479 was een van de vijf Redis-fouten van de RCE-klasse die vorige maand werden onthuld, en volgt op de RediShell-fout van Redis uit 2025, een andere geverifieerde use-after-free met Lua-scripting. Het is ook degene die door een AI-tool is opgevangen. Twee commits hebben het geplant, twee jaar lang verborgen gehouden, en het bleef in een van de meest gebruikte databases staan totdat er een hackwedstrijd aan de oppervlakte kwam. Codebeoordeling heeft dat nooit gedaan.
