Eine Sicherheitslücke in Node.js kann bösartige komprimierte Daten in Remotecodeausführung (RCE) verwandeln. Forscher haben den Angriff gegen eine unveränderte Laufzeitumgebung demonstriert, was Bedenken hinsichtlich Anwendungen weckt, die nicht vertrauenswürdige Brotli-Daten verarbeiten.
Imperva veröffentlichte am 22. Oktober 2026 seinen Node2Shell-Proof-of-Concept und demonstrierte die Codeausführung auf Node.js 24.22.0 unter Linux arm64. Die als CVE-2026-111497 geführte Sicherheitslücke betrifft die Node.js-Releasezweige 22, 24 und 26. Sicherheitsupdates wurden am 21. Oktober veröffentlicht.
Anwendungen, die Express-Middleware oder die integriertefetch() API von Node.js verwenden, können auf den anfälligen Decoder stoßen, ohne ihn direkt aufzurufen. Ob eine Anwendung exponiert ist, hängt davon ab, ob vom Angreifer kontrollierte Brotli-Daten den betroffenen Code erreichen.
Die Node2Shell-Exponierung geht über benutzerdefinierten Dekomprimierungscode hinaus
Node2Shell nutzt einen Out-of-Bounds-Schreibfehler im gebündelten Brotli-Decoder von Node.js aus. Fehlerhafte komprimierte Eingaben können den Speicher beschädigen und dadurch möglicherweise Abstürze, die Offenlegung von Informationen oder Codeausführung verursachen. Verwandte Speichersicherheitsrisiken haben außerdem zuSicherheitsupdates für OpenSSLgeführt, obwohl die Sicherheitslücken auf unterschiedlichen Mechanismen beruhen.
Akamais Analyse vom 26. Oktober berichtet von einem CVSS-v4.0-Wert von 9,2 (kritisch), während Node.js die Sicherheitslücke als schwerwiegend einstuft.
Laut der Untersuchung von Imperva kann eine Exponierung über drei Wege erfolgen:
- Express-5-Middleware: Konfigurierte Request-Parser können Brotli-codierte Request-Bodies dekomprimieren.
- Node.js-
fetch():Anwendungen können bösartige Brotli-Antworten von nicht vertrauenswürdigen Servern dekomprimieren. node:zlib:Dienste, die vom Angreifer kontrollierte Brotli-Datenströme direkt dekomprimieren, können den anfälligen Decoder erreichen.
„Der Fehler ist implementierungsspezifisch und betrifft nicht jeden Server, auf dem Node.js standardmäßig ausgeführt wird“, sagte Yordan Ganchev, Principal Threat Intelligence Specialist bei watchTowr.
Ganchev warnte, dass Abhängigkeiten übersehene Dekomprimierungspfade einführen können. Ähnliche Risiken durch Abhängigkeiten traten bei einerWordPress-Sicherheitslücke beim HEIC-Uploadauf, bei der Bildverarbeitungssoftware Server einer RCE aussetzen konnte.
Die Linux-arm64-Demonstration von Imperva erforderte mehrere Versuche. Die Forscher konnten keine vergleichbare Zuverlässigkeit des Exploits auf anderen Plattformen feststellen, obwohl die zugrunde liegende Sicherheitslücke nicht auf Linux arm64 beschränkt ist.
Gepatchte Node.js-Versionen und Prioritäten bei der Risikominderung
Die Sicherheitswarnung von Node.js nennt die folgenden korrigierten Releases:
| Node.js-Zweig | Mindestversion mit Fix |
|---|---|
| 22.x | 22.23.4 |
| 24.x | 24.22.1 |
| 26.x | 26.12.1 |
Unternehmen sollten das jeweils passende gepatchte Release oder eine neuere korrigierte Version installieren. Nicht unterstützte Installationen müssen auf unterstützte Zweige migriert werden. Eine Aktualisierung von Express oder body-parser allein behebt den Fehler in der Laufzeitumgebung nicht.
Sicherheitsteams sollten sechs Maßnahmen priorisieren:
- Exponierte Anwendungen erfassen: Node.js-Versionen auf Servern, in Containern und in Serverless-Workloads überprüfen. Express,
fetch(), undnode:zlibDekomprimierungspfade ermitteln. - Deployments patchen und überprüfen: Laufzeitumgebungen aktualisieren, betroffene Container-Images neu erstellen und bestätigen, dass in Produktionsprozessen gepatchte Binärdateien verwendet werden.
- Nicht benötigte Dekomprimierung deaktivieren: Die
inflateOption von Express body-parser auffalsesetzen, wenn komprimierte Request-Bodies nicht benötigt werden. - Nicht vertrauenswürdigen Datenverkehr beschränken: Eingehende
Content-Encoding: br-Anfragen vorübergehend blockieren, wo dies angemessen ist, und nicht benötigte ausgehende Verbindungen beschränken. Die Filterung eingehender Verbindungen schützt nicht vorfetch()-Antworten. - Mögliche Kompromittierungen begrenzen: Dienste segmentieren und Berechtigungen der Anwendungen, Dateisystemzugriff sowie Cloud-Anmeldedaten einschränken.
- Pläne für die Reaktion auf Sicherheitsvorfälle überwachen und testen: Ungeklärte Abstürze, Dekomprimierungsfehler, unerwartete untergeordnete Prozesse und verdächtige Verbindungen untersuchen. Anwendungs- und Netzwerkprotokolle korrelieren und Pläne für die Reaktion auf Sicherheitsvorfälle testen.
Die Filterung am Perimeter bietet nur vorübergehenden Schutz. FrüherePeopleSoft-WAF-Bypass-Angriffehaben gezeigt, wie verwundbare Systeme exponiert bleiben können, wenn Filterung an die Stelle von Patches tritt.
Ganchev empfahl, Protokolle mit dem Eintrag „Decompression failed“ zu untersuchen, obwohl solche Fehler keinen Beweis für eine Ausnutzung darstellen. Sicherheitsteams sollten Anwendungen identifizieren, die nicht vertrauenswürdige Brotli-Daten verarbeiten, und überprüfen, dass in der Produktion gepatchte Node.js-Laufzeitumgebungen ausgeführt werden.
Mehr lesen: GitLabs zweiter kritischer RCE-Patch im Oktoberzeigt, warum Administratoren Sicherheits-Releases auch nach der Installation früherer Fixes weiterhin prüfen müssen.