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üfen Sie Ihre 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: Stellen Sie sicher, dass Ihr 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änken Sie, welche Redis-Endpunkte Ihre Anwendung ansprechen darf, insbesondere bei nutzergesteuerten Verbindungszielen. Terminieren Sie Redis-Verbindungen wenn möglich über TLS mit Zertifikatsprüfung, damit sich kein beliebiger Endpunkt als Ihr Redis-Server ausgeben kann. Erwägen Sie, sofern Ihr Setup dies zulässt, einen Wechsel auf einen Redis-Client, der RESP3 nativ ohne die betroffene redis-parser-Bibliothek implementiert.
Detection / Prüfung
Überwachen Sie Ihre 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üfen Sie, ob Ihre Redis-Verbindungen tatsächlich ausschließlich zu vertrauenswürdigen, von Ihnen 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: Ihre Anwendung ioredis nutzt und Verbindungen zu Redis-Instanzen aufbaut, die nicht vollständig unter Ihrer eigenen Kontrolle stehen, etwa bei Multi-Tenant-Setups oder nutzergesteuerten Konfigurationen. Richten Sie Process-Supervision und Netzwerkbeschränkungen umgehend ein.
Beobachten genügt, wenn: Ihre Redis-Instanzen ausschließlich intern und unter eigener Kontrolle laufen und Process-Supervision bereits vorhanden ist. Verfolgen Sie die Fix-Veröffentlichung und planen Sie 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üfen Sie im Zweifel Ihre 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?+
Ihr eigener, vertrauenswürdiger Redis-Server löst das Problem nicht aus. Kritisch wird es, wenn Ihre 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 Ihre Infrastruktur laufend.