Redis läuft in den meisten Web-Stacks einfach so vor sich hin — als Session-Cache, Queue-Backend, Pub/Sub-Broker. Dass in den Versionen ab 7.2.0 seit über zwei Jahren ein Use-After-Free-Bug schlummerte, der authentifizierten Angreifern Remote Code Execution ermöglicht, ist lange niemandem aufgefallen. Bis das autonome Sicherheitstool Xint Code des Unternehmens Theori den Fehler beim Hacking-Wettbewerb ZeroDay.Cloud 2025 in London gefunden hat. Der Patch ist seit dem 5. Mai 2026 verfügbar — für alle betroffenen Branches.
Die Exploit-Kette hinter CVE-2026-23479
Der Fehler steckt in unblockClientOnKey() in src/blocked.c — der Funktion, die blockierte Redis-Clients freigibt, wenn ein Key wieder verfügbar wird. Klassisches Use-After-Free, eingeführt mit Redis 7.2.0. Betroffen sind alle stabilen Branches bis zum Mai-Fix: 7.2.0–7.2.13, 7.4.0–7.4.8, 8.2.0–8.2.5, 8.4.0–8.4.2 und 8.6.0–8.6.2.
Die Exploit-Kette läuft in drei Phasen. Zunächst leckt ein Lua-Skript (EVAL "return tostring(redis.call)" 0) eine Heap-Adresse, die der Angreifer für sein Speicherlayout braucht. Dann manipuliert er die Client-Memory-Limits, gibt den blockierten Client frei und platziert eine gefälschte Client-Struktur exakt an dieser Speicherposition. Im letzten Schritt nutzt updateClientMemoryUsage() die gefälschten Felder für einen Out-of-Bounds-Decrement, der die Global Offset Table umschreibt und strcasecmp() auf system() umsetzt. RCE mit einem Befehl.
CVSS 8.8 — was nach „fast kritisch, aber nicht ganz“ klingt, erklärt sich durch die Voraussetzung: authentifizierter Zugriff mit bestimmten Berechtigungen. Klingt nach Einschränkung, ist es aber nicht zwingend. Wer Redis-Instanzen mit Third-Party-Zugriff betreibt, kompromittierte Credentials im Umlauf hat oder Redis aus Bequemlichkeit nicht hinter einer ordentlichen Firewall betreibt, ist real gefährdet. In meinen KMU-Kundenprojekten läuft Redis erstaunlich oft als „einfach so konfiguriert, nie angefasst“ — genau solche Installationen sind es, bei denen Patches drei oder vier Monate liegen bleiben.
Patches: 7.2.14, 7.4.9, 8.2.6, 8.4.3 und 8.6.3 — alle seit dem 5. Mai 2026 verfügbar. Bekannte Exploits in der freien Wildbahn: laut Redis Inc. bislang keine. Die vollständige Exploit-Kette ist seit heute öffentlich, was das Zeitfenster für Nachzügler kleiner macht.
Wenn KI findet, was Entwickler jahrelang übersehen haben
Interessanter als die Lücke selbst ist, wie sie gefunden wurde. Xint Code ist Theoris Ansatz für automatisiertes Vulnerability Research in großen Codebases — kein Fuzzer im klassischen Sinne, sondern ein Tool, das Taint-Tracking, Datenflussanalyse und Hypothesenbildung über Exploit-Pfade kombiniert. Das Team hat CVE-2026-23479 beim ZeroDay.Cloud 2025-Wettbewerb in London demonstriert und dabei einen funktionierenden RCE gegen Redis präsentiert — der Contest fand im Dezember 2024 statt.
Dass die Lücke über zwei Jahre in einem der meistgenutzten Open-Source-Projekte unentdeckt blieb, ist kein Versagen einzelner Entwickler. Redis ist ein komplexes Projekt mit C-Code aus mehr als einem Jahrzehnt, manuelles Security-Audit ist teuer und in Open-Source-Projekten chronisch unterfinanziert. Was Xint Code hier gezeigt hat: autonome Vulnerability-Suche findet Use-After-Free-Bugs in produktivem C-Code, die Menschen bei einem normalen Review wahrscheinlich übersehen hätten. Das ist kein PR-Claim mehr — das ist ein demonstrierter, funktionierender Exploit.
Einen Punkt lohnt es, im Kopf zu behalten: Zwischen der Contest-Demonstration im Dezember 2024 und dem Patch im Mai 2026 lagen fast 18 Monate. Für Coordinated Disclosure bei einem CVSS-8.8-Bug, der in einem öffentlichen Wettbewerb demonstriert wurde, ist das ein langer Zeitraum. Redis Inc. und Theori haben offenbar eine Embargo-Absprache gehalten — ob 18 Monate bei dieser Severity angemessen sind, ist eine berechtigte Frage.
Wer Redis 7.2.x bis 8.6.x im Einsatz hat und die Mai-Releases noch nicht eingespielt hat, sollte das heute erledigen. Die Exploit-Kette ist öffentlich, der Weg von authentifiziertem Angreifer zu Remote Code Execution detailliert dokumentiert. Ob autonome Tools wie Xint Code dauerhaft verändern, wie Open-Source-Projekte auf ihre eigene Sicherheit schauen — das wird die nächste Generation solcher Wettbewerbe zeigen.
