Node2Shell: Warum Node patchen allein nicht reicht

Node.js hat am 21. Oktober 2026 Sicherheitsupdates für zehn Schwachstellen veröffentlicht. Die schwerste davon, CVE-2026-111497, erlaubt Remote Code Execution über manipulierte Brotli-Daten. Der fehlerhafte Code steht allerdings nicht in Node.js, sondern in der Kompressionsbibliothek, die Node.js mitliefert – und das entscheidet darüber, ob eine aktualisierte Node-Fassung die Lücke überhaupt schließt.

Was Node2Shell ist

Node2Shell ist der Name, unter dem Imperva am 22. Oktober seine Analyse von CVE-2026-111497 veröffentlicht hat: einem Out-of-Bounds-Write im Brotli-Decoder, den Node.js in den Zweigen 22.x, 24.x und 26.x mitbringt. Node.js stuft die Lücke als „high“ ein und hat sie am 21. Oktober behoben. Der CVE-Eintrag bewertet sie strenger, mit CVSS 9.2 nach Version 4.0 und der Stufe kritisch. Gemeldet haben sie Khai Tran und Sylvie Mayer von OpenAI Codex Security, den Fix entwickelten zwei Mitglieder des Node.js-Teams.

Die Lücke erschien am selben Tag wie PHP2Shell und mit derselben Bewertung, CVSS 9.2. Auffällig ist, wer gemeldet hat: Bei PHP waren Forscher von OpenAI unter den Meldern, hier ist es dessen Codex-Security-Team. Wie viel davon auf KI-Werkzeuge zurückgeht, sagen die Advisories nicht – dass die Sicherheitsteams der KI-Anbieter in den Danksagungen stehen, ist seit April Routine.

Der Fehler liegt in Brotli, nicht in Node.js

Der verwundbare Code steht in der Referenzimplementierung von Brotli, Googles Kompressionsformat, in c/dec/decode.c. Beim Dekomprimieren prüft der Decoder, ob ein Datenstrom auf einen anderen Blocktyp umschaltet. Meldete diese Prüfung einen Fehler, gab die zuständige Funktion ihn auf dem schnellen Dekodierpfad nicht weiter – ihre Aufrufer hatten keinen Rückgabewert dafür. Der Decoder arbeitete mit ungültigem internem Zustand weiter und schrieb dabei über den vorgesehenen Puffer hinaus. Der CVE-Eintrag führt das als CWE-252, nicht geprüfter Rückgabewert; der Fix lässt die Funktionen einen Formatfehler zurückgeben und bricht den Datenstrom ab.

Entscheidend für die Reichweite ist die Versionsangabe im CVE-Eintrag: Betroffen sind die Brotli-Fassungen 1.0.3 bis 1.2.0 „on all platforms“, zu aktualisieren sind „any Brotli libraries or binaries“. Korrigiert sind 1.0.10, 1.1.1 und 1.2.1, alle am 21. Oktober erschienen. Node.js ist der bekannteste Abnehmer dieser Bibliothek, nicht der einzige.

Der Decoder ist erreichbar, ohne dass Brotli im Code steht

Eine Anwendung muss Brotli nirgends aufrufen, um den Decoder zu erreichen. Drei Wege führen laut Imperva hinein: der direkte Aufruf über node:zlib, Nodes eingebautes fetch(), das eine Brotli-komprimierte Antwort selbstständig dekomprimiert, und die Request-Parser von Express 5.

Der dritte Weg vergrößert die Angriffsfläche am stärksten. Der Umstiegsleitfaden von Express 5 führt die Brotli-Dekomprimierung als Verbesserung ohne Migrationsschritt: express.json(), express.urlencoded(), express.text() und express.raw() nehmen Content-Encoding: br an. body-parser dokumentiert, alle Parser unterstützten „automatic inflation“ von gzip, br, deflate und zstd; die einzige dafür dokumentierte Option ist inflate mit dem Standardwert true. Einen Schalter nur für Brotli nennt die Dokumentation nicht. Wer express.json() einsetzt und inflate nicht abschaltet, nimmt also Brotli-Körper an, ohne das im eigenen Code zu sehen. Ein nackter HTTP-Server in Node dekomprimiert eingehende Brotli-Körper dagegen nicht allein dadurch, dass er sie empfängt.

Imperva hat diesen Weg bis zur Codeausführung durchgespielt: Im offiziellen Node-Image 24.22.0 für Linux/arm64 legte eine Brotli-Nachricht eine Datei an, für die die Testanwendung keinen Code enthielt – ohne Debugger, aber nicht bei jedem Versuch. 24.22.1 wies die Eingaben ab. Das ist bislang die einzige öffentliche Demonstration; Angriffe in der Praxis melden weder Node.js noch Imperva, und im CISA-KEV-Katalog steht die Lücke mit Stand 23. Oktober nicht.

Warum eine gepatchte Node-Version nicht genügt

Ob node -v eine korrigierte Fassung zeigt, entscheidet nur dort, wo Node seinen eigenen Brotli-Code benutzt. Debians Paket tut das nicht: Im Sicherheits-Tracker steht zu CVE-2026-111497 die Notiz, nodejs nutze die Brotli-Bibliothek des Systems. Entsprechend führt Debian beide Pakete – brotli in Bookworm, Trixie und Sid als „vulnerable“, als behobene Fassung steht „(unfixed)“, und nodejs mit der Dringlichkeit „unimportant“. Auf diesen Systemen schließt erst das Brotli-Paket die Lücke, und am 23. Oktober war es dort nicht verfügbar.

Was jetzt zu tun ist

Die Schritte unterscheiden sich von einem gewöhnlichen Update darin, dass die Node-Version allein nicht über die Lücke entscheidet:

• Laufzeitumgebungen aktualisieren und die Prozesse neu starten: Ein laufender Prozess behält den alten Decoder im Speicher.
• Die Brotli-Bibliothek mitprüfen, wo Node aus einem Distributionspaket kommt: Dort ist libbrotli die verbindliche Angabe.
• Jedes Image einzeln prüfen, nicht nur den Host. In Container-Images und Appliances mit eingebauter Laufzeitumgebung veralten Versionsangaben am schnellsten; eine Paketliste des Hosts zeigt sie nicht.
• Brotli-Verkehr aus unbekannter Quelle begrenzen, solange das Update wartet. inflate: false weist auch gzip und deflate ab und bricht damit möglicherweise bestehende Clients; eine Begrenzung auf betroffenen Pfaden am Webserver oder in der Web Application Firewall trifft enger.
• Die übrigen neun Lücken nicht übersehen. Das Release vom 21. Oktober behebt zehn CVEs, drei weitere davon mit der Stufe „high“: abgeschnittene DNS-Namen mit NUL-Zeichen und zwei Umgehungen der TLS-Hostnamen-Prüfung.
• Decoder-Fehler nicht als Beweis lesen. Abgestürzte Prozesse und Fehler des Decoders sind laut Imperva allein kein verlässliches Zeichen für einen Angriff – aussagekräftig werden sie erst zusammen mit der eingesetzten Fassung und der Herkunft der Daten.

Was hilft – und warum Sichtbarkeit entscheidet

Die Frage am Tag eines solchen Updates ist nicht, wie man Node.js aktualisiert, sondern wo überall eine Laufzeitumgebung läuft. blacklens.io erfasst über Attack Surface Management laufend von außen, welche Dienste und Webanwendungen erreichbar sind und welche Technologien in welchen Versionen darauf laufen; interne Systeme deckt der Sentry Agent ab. Das Threat Center gleicht neue CVEs in Echtzeit mit diesem Inventar ab und weist aus, ob ein Treffer auf der exakten Version beruht oder nur auf dem Produkt.

Eine Grenze gehört dazu: Welche Brotli-Bibliothek ein Node-Prozess geladen hat, verrät kein Dienst von außen. Diese Prüfung bleibt auf dem System – welche Systeme sie betrifft, lässt sich vorher beantworten.