redis-parser CVE-2026-93435: Unbegrenzte Rekursion beim RESP-Parsing legt ioredis-Clients lahm
redis-parser, der von ioredis genutzte RESP-Protokoll-Parser für Node.js, prüft die Verschachtelungstiefe eingehender Redis-Antworten nicht. CVE-2026-93435 (CVSS 7.5 nach v3.1, 8.7 nach v4.0) beschreibt, wie ein bösartiger oder kompromittierter Redis-Endpunkt mit tief verschachtelten Array-Antworten einen Stack Overflow im Client-Prozess auslöst und diesen abstürzen lässt. Betroffen sind redis-parser-Versionen bis 3.0.0. Ein offizieller Fix war zum Zeitpunkt dieses Artikels noch nicht veröffentlicht.
TL;DR — 90 Sekunden
Der RESP-Parser von redis-parser, den ioredis für das Redis-Protokoll nutzt, verarbeitet verschachtelte Array-Antworten rekursiv, ohne die Tiefe zu begrenzen. Antwortet ein Redis-Server mit einem stark verschachtelten Array, wirft Node.js einen RangeError: Maximum call stack size exceeded und der Client-Prozess stürzt ab. Ein Angreifer benötigt dafür Kontrolle über den Redis-Server oder die Fähigkeit, dessen Antworten zu manipulieren, etwa über einen kompromittierten oder vorgetäuschten Redis-Endpunkt. Ein Fix ist bislang nicht veröffentlicht, ioredis-Maintainer haben das Problem bestätigt.
Was ist das Problem?
redis-parser ist die RESP-Protokoll-Implementierung, auf der node_redis und ioredis ursprünglich aufbauten und die ioredis bis heute nutzt. RESP-Array-Antworten können verschachtelt sein, etwa ein Array von Arrays. Der Parser verarbeitet diese Verschachtelung über rekursive Funktionsaufrufe, einen pro Verschachtelungsebene, ohne eine maximale Tiefe zu erzwingen.
ioredis reicht eingehende Socket-Daten direkt an parser.execute(data) weiter. Antwortet der verbundene Redis-Server, oder ein Angreifer, der sich als solcher ausgibt, mit einem Array, das viele tausend Ebenen tief verschachtelt ist, erschöpft die Rekursion den Node.js-Aufrufstack. Die Folge ist ein unkontrollierter Absturz des Client-Prozesses über eine RangeError-Ausnahme, die ioredis derzeit nicht in eine kontrollierte Fehlerbehandlung umwandelt.
Wer ist betroffen?
Betroffen sind Anwendungen, die ioredis mit einer verwundbaren redis-parser-Version einsetzen und Antworten von einem Redis-Server verarbeiten, der nicht vollständig vertrauenswürdig ist, etwa bei SSRF-artigen Konstellationen, kompromittierten Redis-Instanzen oder Verbindungen über nicht authentifizierte Netzwerksegmente.
| CVE | Paket | Betroffen | Fix | CVSS |
|---|---|---|---|---|
| CVE-2026-93435 | redis-parser (Abhängigkeit von ioredis) | redis-parser ≤ 3.0.0 | noch nicht veröffentlicht | 7.5 / 8.7 |
Wie viele aktuelle ioredis-Versionen konkret die verwundbare redis-parser-Version einbinden, war zum Zeitpunkt dieses Artikels aus den verfügbaren Quellen nicht abschließend zu bestimmen. Prüfe deine eigene Dependency-Auflösung mit npm ls redis-parser.
Auswirkungen
Ein erfolgreicher Angriff beendet den Node.js-Prozess, der die Redis-Verbindung hält, unkontrolliert. Bei Anwendungen ohne Process-Supervision, etwa PM2, systemd mit Neustart-Policy oder ein Orchestrator wie Kubernetes, bedeutet das einen vollständigen Ausfall des betroffenen Dienstes, nicht nur der Redis-Verbindung.
Vertraulichkeit und Integrität sind nach aktuellem Kenntnisstand nicht betroffen, es handelt sich um eine reine Denial-of-Service-Schwachstelle. Da ioredis in vielen Node.js-Backends für Sessions, Caching und Queues zentral eingebunden ist, kann der Ausfall dennoch Kaskadeneffekte auf abhängige Dienste haben.
Mitigation / Sofortmaßnahmen
Ein offizieller Fix stand zum Zeitpunkt dieses Artikels noch aus. Bis dahin: Stell sicher, dass dein Node.js-Prozess unter Process-Supervision läuft, etwa systemd, PM2 oder eine Kubernetes-Restart-Policy, damit ein Absturz automatisch zu einem Neustart statt zu einem dauerhaften Ausfall führt.
Beschränke, welche Redis-Endpunkte deine Anwendung ansprechen darf, insbesondere bei nutzergesteuerten Verbindungszielen. Terminiere Redis-Verbindungen wenn möglich über TLS mit Zertifikatsprüfung, damit sich kein beliebiger Endpunkt als dein Redis-Server ausgeben kann. Erwäge, sofern dein Setup dies zulässt, einen Wechsel auf einen Redis-Client, der RESP3 nativ ohne die betroffene redis-parser-Bibliothek implementiert.
Detection / Prüfung
Überwache deine Node.js-Prozesse auf unerwartete Neustarts oder Abstürze mit RangeError: Maximum call stack size exceeded im Stacktrace, insbesondere wenn dieser aus dem redis-parser- oder ioredis-Modul stammt.
Prüfe, ob deine Redis-Verbindungen tatsächlich ausschließlich zu vertrauenswürdigen, von dir kontrollierten Redis-Instanzen aufgebaut werden. Auffällig sind insbesondere Verbindungen zu Redis-Endpunkten, deren Antwortverhalten sich kürzlich geändert hat, oder ungewöhnlich große Antwortpakete unmittelbar vor einem Absturz.
Betreiberempfehlung
Akut handeln, wenn: deine Anwendung ioredis nutzt und Verbindungen zu Redis-Instanzen aufbaut, die nicht vollständig unter deiner eigenen Kontrolle stehen, etwa bei Multi-Tenant-Setups oder nutzergesteuerten Konfigurationen. Richte Process-Supervision und Netzwerkbeschränkungen umgehend ein.
Beobachten genügt, wenn: deine Redis-Instanzen ausschließlich intern und unter eigener Kontrolle laufen und Process-Supervision bereits vorhanden ist. Verfolge die Fix-Veröffentlichung und plane das Update ein.
Häufige Fragen zu CVE-2026-93435
Ist node_redis (der offizielle Redis-Client) auch betroffen?+
Die aktuellen Hauptversionen von node_redis (ab v4) nutzen einen eigenen RESP3-Parser und nicht mehr das historische redis-parser-Paket. Prüfe im Zweifel deine eigene Dependency-Auflösung.
Reicht Process-Supervision als dauerhafte Lösung?+
Process-Supervision verhindert einen dauerhaften Ausfall, behebt aber nicht die zugrundeliegende Schwachstelle. Jeder Neustart unterbricht laufende Verbindungen und Anfragen kurzzeitig. Ein Patch bleibt notwendig, sobald verfügbar.
Muss ich meinen eigenen Redis-Server absichern, oder reicht das nicht?+
Dein eigener, vertrauenswürdiger Redis-Server löst das Problem nicht aus. Kritisch wird es, wenn deine Anwendung Verbindungen zu Redis-Endpunkten aufbaut, die ein Angreifer kontrollieren oder vortäuschen kann.
Wurde ein CVE für ioredis selbst vergeben?+
Nein. CVE-2026-93435 ist gegen die Abhängigkeit redis-parser vergeben. Der zugehörige ioredis-Issue #2108 dokumentiert den Effekt auf ioredis-Anwendungen.
Gibt es einen Workaround ohne Codeänderung?+
Ein vorgeschalteter Proxy oder ein Netzwerk-Policy-Regelwerk, das Verbindungen auf bekannte, vertrauenswürdige Redis-Endpunkte beschränkt, reduziert das Risiko ohne Codeänderung. Es ersetzt aber keinen Patch.
Fazit
Der Fall erinnert daran, dass Protokoll-Parser für Netzwerkdienste grundsätzlich von nicht vertrauenswürdigen Eingaben ausgehen sollten, auch wenn der Gegenpart üblicherweise die eigene Infrastruktur ist. Eine unbegrenzte Rekursion in einem weit verbreiteten, aber wenig beachteten Abhängigkeitspaket wie redis-parser reicht aus, um produktive Node.js-Dienste lahmzulegen.
Quellen
Ich unterstütze bei der Härtung von Node.js-Backends gegen Denial-of-Service-Schwachstellen in Abhängigkeiten und beim Aufsetzen belastbarer Process-Supervision für Redis-gestützte Dienste.
Dependency-Audits für Node.js- und PHP-Stacks, Process-Supervision- und Restart-Policy-Setup, Netzwerksegmentierung für Datenbankverbindungen.
Plattform-Betrieb statt Beratung auf Papier: Ich prüfe, patche und härte deine Infrastruktur laufend.