Node2Shell ermöglicht code execution in standardmäßigem Node.js build
Node2Shell, eine Node.js-Sicherheitslücke im mitgelieferten Brotli-Decoder, kann laut einer Demonstration von Imperva-Forschern schädliche komprimierte Daten in vom Angreifer bereitgestellten Code innerhalb einer Anwendung umwandeln. Node.js ist Software, mit der JavaScript außerhalb eines Webbrowsers ausgeführt wird, unter anderem in Webanwendungen und Diensten. Brotli ist ein Format zur Datenkomprimierung. Die unter dem Common-Vulnerabilities-and-Exposures-Kennzeichen (CVE) CVE-2026-111497 geführte Sicherheitslücke kann zu remote code execution (RCE) führen. Das bedeutet, dass ein Angreifer die betroffene Anwendung dazu bringen kann, Befehle oder Software seiner Wahl auszuführen.
Imperva erreichte code execution auf dem offiziellen Node.js-24.22.0-Image für Linux arm64, die 64-Bit-ARM-Prozessorarchitektur. Für den Test wurde ein reguläres Release und kein speziell abgeschwächter build verwendet; außerdem war kein Debugger erforderlich, also kein Werkzeug zur Untersuchung eines laufenden Programms. Das Ergebnis ließ sich jedoch nicht bei jedem Versuch zuverlässig erzielen. Imperva benötigte in seiner Linux-arm64-Umgebung mehrere Versuche, bevor der bereitgestellte Code ausgeführt wurde. Die Forscher testeten weder andere Prozessorarchitekturen noch die Node.js-Release-Linien 22.x und 26.x. Das demonstrierte Ergebnis ist daher auf diesen build und diese Anwendungskonfiguration beschränkt.
Node.js veröffentlichte die Sicherheitslücke und stellte am 21. Oktober Korrekturen bereit. Als Imperva den Test mit dem korrigierten Release 24.22.1 wiederholte, wies die runtime die präparierten Daten zurück und führte den bereitgestellten Code nicht aus. Bis zum 22. Oktober waren keine Ausnutzungen bei realen Angriffen gemeldet worden. Dass kein Missbrauch gemeldet wurde, beseitigt jedoch nicht die Notwendigkeit, Anwendungen zu aktualisieren, die Brotli-Daten aus nicht vertrauenswürdigen Quellen verarbeiten.
Die Node2Shell-Demonstration geht weiter als der erste öffentlich verfügbare proof of concept, also Testcode, mit dem gezeigt werden soll, ob sich eine Sicherheitslücke auslösen lässt. Bei dieser früheren Arbeit wurde code execution nur auf einem absichtlich abgeschwächten Test-build erreicht. Der Autor berichtete, dass derselbe Ansatz bei einem normalen build einen Absturz verursachte und eine begrenzte Menge an Prozessspeicher offenlegte, dort aber keine funktionierende code execution ermöglichte. Das Ergebnis von Imperva zeigt, dass eine Ausnutzung auf einem offiziellen, standardmäßigen Node.js build möglich war, wobei die unzuverlässige Erfolgsrate und der enge Testumfang weiterhin wichtige Einschränkungen darstellen.
Der zugrunde liegende Decoder ist in Node.js 22.x, 24.x und 26.x enthalten, weshalb die Gefährdung nicht auf genau die von Imperva verwendete Version beschränkt ist. Eine Anwendung kann den anfälligen Decoder aus beiden Richtungen eines Hypertext-Transfer-Protocol-Austauschs (HTTP) erreichen, dem von Websites und Webdiensten verwendeten Request-and-Response-System. Ein Weg führt über die integrierte Funktion fetch(), die eine Brotli-komprimierte Response von einem anderen Server liest. Der andere führt über middleware, also Software zwischen einem eingehenden Request und der Anwendung, die einen Brotli-komprimierten Request-Body decodiert.
Die Body-Parser von Express 5, darunter express.json(), express.urlencoded(), express.text() und express.raw(), können Brotli-komprimierte Request-Bodys decodieren, wenn sie für eine Route aktiviert sind. Sie unterstützen außerdem die Kompressionsformate gzip und deflate. Der bloße Empfang eines Brotli-komprimierten Requests durch einen einfachen Node.js-HTTP-Server reicht nicht aus, um den betroffenen Code aufzurufen. Die Anwendung muss geeignete middleware zur Decodierung verwenden oder den Decoder direkt aufrufen.
Imperva reproduzierte code execution sowohl über den Pfad des eingehenden Request-Bodys als auch über den Pfad der ausgehenden Response. Bei den Tests kamen festgelegte, gezielt ausgewählte Versionen von Express von 5.0.0 bis 5.3.0 und von body-parser von 2.0.0 bis 2.3.0 zum Einsatz. Die Forscher testeten nicht jedes Release zwischen diesen Endpunkten. Die Ergebnisse sollten daher nicht als versionsweise Bewertung dieser Pakete verstanden werden.
Der Defekt tritt auf, wenn der Brotli-Stream einen Blockwechsel erreicht, der gemäß der bereits von demselben Stream deklarierten Struktur unmöglich sein sollte. Anstatt die Daten als ungültig zu behandeln, interpretierte der anfällige Decoder den Zustand als Anforderung weiterer Eingabedaten und setzte die Verarbeitung in einem ungültigen Zustand fort. In einem separaten Test mit einem memory sanitizer, einem Diagnosewerkzeug zur Erkennung unsicherer Speicherzugriffe, beobachtete Imperva einen out-of-bounds write. Das bedeutet, dass der Decoder Daten außerhalb des dafür vorgesehenen Speicherbereichs schrieb. Node.js behob das Problem durch die Übernahme einer Upstream-Änderung an Brotli, die an dieser Stelle die Decodierung beendet und einen Formatfehler zurückgibt.
Die wichtigste Gegenmaßnahme ist die Installation eines gepatchten Node.js-Release. Administratoren müssen außerdem container images und andere paketierte Artefakte aktualisieren, die eine eigene Node.js-Binärdatei enthalten, da ein Softwareinventar möglicherweise nicht jede mitgelieferte Kopie erfasst. Node.js 20.x und frühere Release-Linien sind end-of-life, erhalten diese Korrektur also nicht mehr, und sollten auf eine unterstützte Release-Linie migriert werden.
Das Node.js-Advisory nennt keinen Workaround innerhalb der runtime. Wo ein sofortiges Update nicht möglich ist, empfiehlt Imperva, nicht vertrauenswürdigen Brotli-Datenverkehr auf betroffenen Request- und Response-Pfaden nach Möglichkeit einzuschränken. Zugleich betont das Unternehmen, dass die Sicherheitslücke nur durch ein Update beseitigt wird. Imperva ergänzte seine eigene web application firewall (WAF), einen Filterdienst vor Webanwendungen, um entsprechende Regeln und testete diese Regeln gegen die reproduzierten Angriffe. Vercel erklärte, am 21. Oktober Regeln für eingehende Requests eingeführt zu haben. Diese Regeln schützen jedoch keine Anwendungen, die schädliche Brotli-Responses von anderen Servern abrufen, und ersetzen das Patchen nicht.
Für Websitebetreiber stellt sich unmittelbar die Frage, ob ihre Anwendung, ihr Hosting-Image oder ihr Deployment-Paket eine betroffene Node.js runtime enthält und nicht vertrauenswürdige Brotli-Daten verarbeitet. Organisationen, die Unterstützung bei der Prüfung der Wartung von runtime und Infrastruktur benötigen, können AEU-I in Betracht ziehen, das sicherheitsorientierte IT-, Infrastruktur- und Beratungsleistungen anbietet. Unabhängig von der Hosting-Konfiguration besteht die wirksame Behebung von Node2Shell darin, betroffene Node.js-Binärdateien zu ersetzen, mitgelieferte Artefakte bei Bedarf neu zu erstellen und die aktualisierte Anwendung erneut bereitzustellen.