Kritische Redis RCE (CVE-2026-23479) durch KI-Tool entdeckt: Sofortiges Patchen empfohlen
Eine schwerwiegende Use-after-free-Schwachstelle, **CVE-2026-23479**, wurde in **Redis** entdeckt, die es authentifizierten Angreifern ermöglicht, beliebige OS-Befehle auszuführen. Der Fehler, der seit Version 7.2.0 besteht, wurde einzigartig von einem autonomen KI-Sicherheitstool identifiziert und stellt ein erhebliches Risiko dar, insbesondere für Cloud-Deployments, bei denen viele **Redis**-Instanzen keine robuste Authentifizierung aufweisen.
### KI-entdeckte RCE bedroht Redis-Deployments
Eine kritische Remote Code Execution (RCE)-Schwachstelle, verfolgt als **CVE-2026-23479**, wurde im beliebten Open-Source-In-Memory-Datenspeicher **Redis** behoben. Dieser Use-after-free-Fehler ermöglicht es einem authentifizierten Angreifer, beliebige Betriebssystembefehle auf der Maschine auszuführen, die die Datenbank hostet, was ein erhebliches Sicherheitsrisiko für betroffene Systeme darstellt.
Die Schwachstelle wurde einzigartig von **Xint Code**, einem autonomen KI-Sicherheitstool von **Theori**, entdeckt und von **Team Xint Code** gemeldet. Dies unterstreicht die sich entwickelnde Landschaft der Schwachstellenforschung, in der KI zunehmend eine Rolle bei der Identifizierung komplexer Fehler in großen Codebasen spielt.

### Die Schwachstelle: CVE-2026-23479 erklärt
Der Use-after-free-Fehler befindet sich in der Funktion `unblockClientOnKey()` in `src/blocked.c`, die ausgelöst wird, wenn ein Schlüsselereignis einen blockierten Befehl weckt. Die Funktion leitet den wartenden Befehl über `processCommandAndResetClient()` weiter. Entscheidend ist, dass `processCommandAndResetClient()` als Nebeneffekt den übergebenen Client-Zeiger freigeben kann. Der Aufrufer von `unblockClientOnKey()` verwendet diesen nun freigegebenen Client-Zeiger weiter, was zu einer klassischen Use-after-free (CWE-416)-Bedingung führt.
Dieser Fehler wurde in **Redis** 7.2.0 eingeführt und blieb in allen stabilen Zweigen bis zur Behebung am 5. Mai bestehen, nachdem er über zwei Jahre unbemerkt geblieben war. Die National Vulnerability Database (NVD) bewertet ihn mit 8,8 unter CVSS 3.1, während **Redis** ihn selbst mit 7,7 unter CVSS 4.0 einstuft. Ein detaillierter technischer Bericht wurde von **Wiz** veröffentlicht.
### Wie der Exploit abläuft
Die Exploit-Kette, die von **Team Xint Code** auf der ZeroDay.Cloud 2025-Konferenz von **Wiz** demonstriert wurde, ist ausgeklügelt und umfasst mehrere Stufen:
1. **Heap-Adressen-Leak**: Ein einzeiliges Lua-Skript (`EVAL "return tostring(redis.call)" 0`) wird verwendet, um einen Heap-Zeiger zu leaken.
2. **Memory Grooming und Fake Client Injection**: Der Angreifer manipuliert die Speicherlimits des Clients, parkt einen großen Client auf einem Stream, reduziert dann die Limits und weckt ihn. Dies führt dazu, dass **Redis** den blockierten Client mitten im Aufruf freigibt. Ein gepipelter `SET`-Befehl belegt den freigegebenen Speicherplatz sofort mit einer präparierten Fake-Client-Struktur wieder.
3. **Function Pointer Overwrite**: Die Routine-Speicherbuchhaltung von **Redis** in `updateClientMemoryUsage()` wird dann genutzt, um eine Out-of-Bounds-Dekrementierung mit vom Angreifer gesteuerten Feldern durchzuführen. Dies zielt auf die Global Offset Table (GOT) ab, um den Funktionszeiger von `strcasecmp()` auf `system()` umzuleiten. Der nächste von **Redis** analysierte Befehl wird dann als Shell-Befehl ausgeführt.
Das Standard **Redis Docker**-Image vereinfacht die letzte Stufe weiter, indem es nur teilweise RELRO mitliefert, wodurch die GOT zur Laufzeit beschreibbar bleibt.
### Voraussetzungen und Cloud-Exposition
Die Ausnutzung von **CVE-2026-23479** erfordert eine authentifizierte Sitzung mit spezifischen ACL-Kategorien: `@admin`, `CONFIG SET`, `EVAL`, Stream-Befehle (`XREAD`/`XADD`) und grundlegende `SET`/`GET`-Befehle. Obwohl dies restriktiv erscheinen mag, besitzen in vielen Standard **Redis**-Deployments die Standardbenutzer alle diese Berechtigungen.
Die Analyse von **Wiz** hebt eine erhebliche Besorgnis hervor: Eine große Mehrheit der **Redis**-Instanzen in Cloud-Umgebungen läuft ohne Passwort. Diese weit verbreitete Konfiguration erhöht die Angriffsfläche dramatisch, da ein Angreifer nur den anfänglichen Zugriff auf die **Redis**-Instanz erhalten muss, um potenziell RCE zu erreichen.

### Sofortige Maßnahmen erforderlich: Patchen und Mitigation
**Redis** hat Patches für diese Schwachstelle veröffentlicht, und sofortige Upgrades werden dringend empfohlen. Die betroffenen Zweige und ihre entsprechenden behobenen Versionen sind:
| Branch | Betroffene Versionen | Behobene Version |
| :----- | :------------------ | :------------ |
| 7.2.x | 7.2.0 bis 7.2.13 | 7.2.14 |
| 7.4.x | 7.4.0 bis 7.4.8 | 7.4.9 |
| 8.2.x | 8.2.0 bis 8.2.5 | 8.2.6 |
| 8.4.x | 8.4.0 bis 8.4.2 | 8.4.3 |
| 8.6.x | 8.6.0 bis 8.6.2 | 8.6.3 |
Kleinere Upgrades innerhalb einer Serie sind als Drop-in-Ersatz konzipiert. Managed **Redis**-Dienste rollen Patches nach ihren eigenen Zeitplänen aus, wobei **Redis Cloud** bereits aktualisiert wurde.
Wenn ein sofortiges Patchen nicht möglich ist, implementieren Sie die folgenden Mitigationen:
* **Netzwerksegmentierung**: Halten Sie **Redis**-Instanzen vom öffentlichen Internet fern und hinter robusten Firewalls.
* **TLS-Verschlüsselung**: Stellen Sie sicher, dass die gesamte **Redis**-Kommunikation mit TLS gesichert ist.
* **Strikte ACLs**: Verschärfen Sie Access Control Lists (ACLs), um zu verhindern, dass eine einzelne Rolle gleichzeitig `@admin`, `CONFIG` und `@scripting`-Berechtigungen besitzt.
* **Lua-Scripting deaktivieren**: Wenn nicht aktiv genutzt, verweigern Sie die `@scripting`-ACL-Kategorie, was den Heap-Leak der Stufe 1 verhindert.
* **Credential Rotation**: Rotieren Sie alle breit geteilten **Redis**-Anmeldeinformationen.
Priorisieren Sie das Patchen und die Mitigation für internetexponierte Instanzen, solche mit gemeinsam genutzten Anwendungsanmeldeinformationen und alle Rollen, die `CONFIG`, Scripting und Stream-Zugriff kombinieren.
### Ein breiterer Kontext
**CVE-2026-23479** ist eine von fünf RCE-Klassen **Redis**-Fehlern, die letzten Monat bekannt gegeben wurden, und folgt dem **RediShell**-Fehler von 2025, einem weiteren authentifizierten Use-after-free mit Lua-Scripting. Die Tatsache, dass ein KI-Tool und nicht eine traditionelle Code-Überprüfung diese langjährige Schwachstelle identifiziert hat, unterstreicht die Notwendigkeit kontinuierlicher Sicherheitsinnovationen und robuster Testmethoden in kritischer Software. Obwohl es noch keine öffentlichen Beweise für eine Ausnutzung in freier Wildbahn gibt, sind die vollständigen technischen Details nun öffentlich, was das Risiko erheblich erhöht.