Analyse der neuen Redis RCE-Schwachstelle CVE-2026-23479

Am 5. Mai hat Redis Patches veröffentlicht für fünf Schwachstellen der Klasse RCE, von denen die schwerwiegendste — CVE-2026-23479 — von der NVD mit einem CVSS-Score von 8.8 (v3.1) bewertet wurde. Es handelt sich um einen Fehler des Typs use-after-free (CWE-416), der in allen stabilen Redis-Zweigen seit Version 7.2.0 vorhanden war — also seit mehr als zwei Jahren. Ein öffentlicher Exploit ist bereits verfügbar, auch wenn bislang keine Fälle einer Ausnutzung in realen Angriffen festgestellt wurden. Alle Administratoren von Redis-Instanzen sollten auf die Versionen 7.2.14, 7.4.9, 8.2.6, 8.4.3 oder 8.6.3 aktualisieren, und falls ein sofortiges Update nicht möglich ist, die ACL-Privilegien und den Netzwerkzugang zum Server einschränken.

Technischer Kern der Schwachstelle

Die Schwachstelle befindet sich in der Funktion unblockClientOnKey() in der Datei src/blocked.c. Diese Funktion wird aufgerufen, wenn ein blockierender Befehl aufgrund eines Key-Events wieder aufgeweckt wird. Sie übergibt den in die Warteschlange eingereihten Befehl an processCommandAndResetClient() und verwendet anschließend denselben Zeiger auf die Client-Struktur weiter. Das Problem besteht darin, dass processCommandAndResetClient() den Client als Nebeneffekt freigeben kann — darauf weist der Kommentar im Funktionskopf ausdrücklich hin. Der aufrufende Code ignoriert den Rückgabewert und greift auf bereits freigegebenen Speicher zu.

Nach Angaben der Forschenden entstand der Bug durch das Zusammenspiel zweier Commits. Ein Refactoring im Januar 2023 (PR #11012) fügte einen nicht geprüften Aufruf hinzu. Eine Änderung im März 2023 (PR #11568) ergänzte einen zusätzlichen Zugriff auf die Client-Struktur nach diesem Aufruf. Keiner der Commits für sich allein erzeugte eine Schwachstelle — gefährlich wurde erst ihre Kombination, die mit Version 7.2.0 allgemein verfügbar wurde.

Redis bewertet die Schwachstelle nach CVSS 4.0 mit 7,7, was unter der Bewertung der NVD liegt. Die Abweichung ergibt sich aus Unterschieden in den Bewertungsmethodiken der Versionen 3.1 und 4.0 und ist kein Ausdruck unterschiedlicher Einschätzungen der Schwere.

Veröffentlichte Exploit-Kette

Eine vollständige technische Beschreibung des Exploits ist bereits veröffentlicht. Demnach besteht die Angriffskette aus drei Phasen:

• Leak der Heap-Adresse. Ein einzeiliger Lua-Skript (EVAL "return tostring(redis.call)" 0) gibt einen Zeiger auf den Heap zurück, der für weitere Berechnungen benötigt wird.
• Austausch der Client-Struktur. Der Angreifer manipuliert die Speicherkontingente des Clients, blockiert den „aufgeblähten“ Client auf einem Stream, setzt anschließend die Limits zurück und weckt ihn wieder auf. Redis gibt den blockierten Client mitten in der Verarbeitung frei, und ein gepipelinter SET-Befehl belegt den freigewordenen Slot sofort mit einer gefälschten Client-Struktur.
• Überschreiben eines Funktionszeigers. Der reguläre Mechanismus zur Speicherkontrolle in updateClientMemoryUsage() führt mit einem Dekrement einen Out-of-Bounds-Zugriff aus und nutzt dabei vom Angreifer kontrollierte Felder. Das Ziel ist die Global Offset Table (GOT): strcasecmp() wird auf system() umgebogen. Der nächste Befehl, den Redis parst, wird dann als Shell-Kommando ausgeführt.

Das offizielle Docker-Image von Redis wird den Forschenden zufolge mit partiellem RELRO ausgeliefert, wodurch die GOT zur Laufzeit weiterhin schreibbar bleibt. ASLR und PIE helfen nicht, da der Schreibzugriff relativ zu einer globalen Variable mit zur Build-Zeit festem Offset erfolgt.

Voraussetzungen für die Ausnutzung und Umfang der Bedrohung

Die vollständige Exploit-Kette erfordert eine authentifizierte Session mit den Privilegien CONFIG SET, EVAL, Stream-Befehlen (XREAD/XADD) und den Basisbefehlen SET/GET. In den Begriffen der Redis-ACL sind dies die Kategorien @admin, @scripting, @stream, @read und @write. Der Standardbenutzer verfügt über all diese Privilegien.

Die Schwachstelle wurde vom Team Team Xint Code entdeckt. Das Unternehmen Theori beschreibt Xint Code als KI-basiertes, eigenständiges Security-Tool, das dazu entwickelt wurde, Fehler in großen Codebasen zu finden. Dies ist ein bemerkenswerter Fall: Zwei Commits erzeugten eine Schwachstelle, sie passierte über zwei Jahre hinweg zahlreiche Code-Reviews, und letztlich wurde sie nicht von einem Menschen, sondern von einem automatisierten Tool im Rahmen eines Hacking-Wettbewerbs gefunden.

Redis erklärte, dass es keine Hinweise auf eine Ausnutzung in den eigenen Umgebungen oder in denen von Kunden gibt. Zum Zeitpunkt der Veröffentlichung lagen keine Meldungen über eine Ausnutzung in realen Angriffen vor. Die Veröffentlichung der vollständigen technischen Kette erhöht das Risiko einer späteren Ausnutzung jedoch erheblich.

Praktische Empfehlungen

Priorität hat ein sofortiges Update. Installieren Sie die gepatchten Versionen für Ihre Release-Serie:

• Redis 7.2 → 7.2.14
• Redis 7.4 → 7.4.9
• Redis 8.2 → 8.2.6
• Redis 8.4 → 8.4.3
• Redis 8.6 → 8.6.3

Redis Cloud ist nach Angaben des Herstellers bereits aktualisiert. Gemanagte Services anderer Provider werden nach deren eigenen Zeitplänen aktualisiert — erkundigen Sie sich nach dem Status bei Ihrem Anbieter.

Falls ein sofortiges Update nicht möglich ist:

• Verhindern Sie den direkten Zugriff auf Redis aus dem Internet und platzieren Sie es hinter TLS.
• Trennen Sie ACL-Privilegien: Keine Rolle sollte gleichzeitig über @admin, CONFIG und @scripting verfügen.
• Verbieten Sie die Kategorie @scripting, wenn Lua-Skripte nicht genutzt werden — dadurch wird die erste Phase der Kette (Leak der Heap-Adresse) blockiert.
• Ein Verbot von CONFIG unterbindet die konkret veröffentlichte Kette, beseitigt aber nicht den zugrunde liegenden use-after-free-Fehler.
• Rotieren Sie alle gemeinsam genutzten Redis-Zugangsdaten.

Konzentrieren Sie sich zunächst auf Instanzen, die aus dem Internet erreichbar sind, auf gemeinsam genutzte Anwendungskonten und auf alle Rollen, die Zugriff auf CONFIG, Skripte und Streams kombinieren.

CVE-2026-23479 ist eine von fünf RCE-Schwachstellen, die in einem einzigen Redis-Patch-Paket offengelegt wurden, und bereits der zweite use-after-free-Bug in Redis innerhalb kurzer Zeit, der mit Lua-Scripting zusammenhängt. Das Vorhandensein eines öffentlichen PoC bei einer massenhaften Redis-Verbreitung macht das Zeitfenster für ein sicheres Update extrem klein. Aktualisieren Sie betroffene Instanzen auf die gepatchten Minor-Releases jetzt — nicht erst, wenn die ersten Angriffsberichte auftauchen.