Wer einen Onlineshop, ein Kundenportal oder eine interne Web-App auf Basis von Node.js betreibt, sollte in dieser Woche die Laufzeitumgebung aktualisieren. Die Sicherheitslücke CVE-2026-111497, unter dem Namen „Node2Shell“ bekannt geworden, steckt im Brotli-Decoder von Google, den Node.js mitbringt. Präparierte, mit Brotli komprimierte Daten können damit Speicher überschreiben und im schlimmsten Fall fremden Code auf dem Server ausführen. Node.js hat am 21. Oktober 2026 die korrigierten Versionen 22.23.4, 24.22.1 und 26.12.1 veröffentlicht. Angriffe in freier Wildbahn sind bislang nicht bekannt. Ein öffentlicher Proof of Concept dagegen schon.
Was hinter Node2Shell steckt
Brotli ist ein Kompressionsverfahren, das Webserver und Browser nutzen, um Daten kleiner zu übertragen. Der Fehler sitzt beim Entpacken. Nach der Analyse des Sicherheitsunternehmens Imperva lief der Decoder bei einem eigentlich unmöglichen Blockwechsel weiter, als warte er nur auf mehr Daten. Die Folge: ein Schreibzugriff jenseits des Puffers. Betroffen sind die Brotli-Versionen 1.0.3 bis 1.2.0, und weil die Bibliothek seit Jahren in unzähligen Programmen steckt, ist die Liste der Software, die sie mitbringt, entsprechend lang. Google bewertet die Lücke mit 9,2 von 10 Punkten auf der Skala CVSS 4.0, das Node.js-Projekt stuft sie als „hoch“ ein.
Wer die Lücke gefunden hat
Laut Sicherheitshinweis von Node.js meldete Matteo Collina den Fehler, Antoine du Hamel schrieb die Korrektur. OpenAI erklärte, das eigene Red Team sei bei einem Test auf den Fehler gestoßen und habe das Brotli-Projekt informiert. Den Namen „Node2Shell“ prägte Ron Masas von Imperva, dessen Team den Angriff nachstellte. Pikant: Im Quellcode von Brotli war die Ursache bereits im Februar 2026 behoben, eine neue Version mit der Korrektur erschien aber erst jetzt.
Wie ein Angriff ablaufen kann
Zwei Wege sind beschrieben, und beide setzen voraus, dass die Anwendung Brotli-Daten aus einer Quelle entpackt, die ein Angreifer kontrollieren kann. Im ersten ruft eine Node.js-Anwendung mit der eingebauten Funktion fetch() Daten von einem fremden Server ab, und dieser liefert eine manipulierte Brotli-Antwort. Im zweiten schickt ein Angreifer komprimierte Daten an einen Server, der eingehende Anfragen selbst entpackt. Das tun etwa Express 5.0.0 bis 5.3.0 und body-parser 2.0.0 bis 2.3.0, wenn sie entsprechend konfiguriert sind. Ein nackter Node.js-HTTP-Server tut das nicht. Imperva gelang die Codeausführung auf dem offiziellen Image von Node.js 24.22.0, allerdings erst nach mehreren Versuchen. Version 24.22.1 wies dieselben Daten ab.
Nicht nur Node.js ist betroffen
Weil Brotli als Bibliothek in vielen Programmen steckt, reicht das Problem weiter. Die Sicherheitsfirma Aikido spricht deshalb inzwischen auch von „HTTP2Shell“ und listet weitere betroffene Komponenten auf.
Die wichtigsten Komponenten und ihre Updates
Für Python sind die Pakete Brotli bis Version 1.2.0 und brotlicffi 1.2.0.x betroffen, korrigiert sind Brotli 1.2.1 und brotlicffi 1.2.1.0. Python-Clients wie urllib3, requests, httpx oder aiohttp entpacken Brotli automatisch, sobald das Paket installiert ist, was bedeutet, dass auch Skripte für Datenimporte, Preisabgleiche oder Schnittstellen zu Lieferanten betroffen sein können, die niemand als Webanwendung auf dem Zettel hat. Bun: ab 1.4.4. Für den Proxy Envoy nennt Aikido die Versionen 1.40.0, 1.39.3, 1.38.6 und 1.37.8, für Istio 1.29.9, 1.30.6 und 1.31.2. Auch curl und libcurl sind betroffen, sofern sie mit Brotli gebaut wurden. Entwarnung gibt es für das Apache-Modul mod_brotli, das nur komprimiert. Apache und Nginx entpacken Brotli standardmäßig nicht.
Das Problem mit alten Versionen
Node.js 18 und 20 bekommen kein Update mehr. Wer solche Versionen noch einsetzt, etwa in einer älteren Kundenanwendung, die seit Jahren unverändert läuft, muss auf eine unterstützte Version wechseln. Mit demselben Update hat Node.js übrigens neun weitere Fehler behoben, darunter mehrere Lücken bei der Prüfung von TLS-Zertifikaten.
Was Unternehmen jetzt tun sollten
Viele kleine und mittlere Firmen betreiben Node.js, ohne es zu wissen, weil es in einem Shopsystem, einem Headless-CMS oder einer von einer Agentur gebauten Web-App steckt. Der erste Schritt ist deshalb eine Bestandsaufnahme, und zwar über alle Systeme hinweg, die von außen erreichbar sind oder selbst Daten aus dem Netz abrufen.
Die Checkliste für die nächsten Tage
Bestand klären
Fragen Sie Agentur, Hoster oder IT-Dienstleister schriftlich, ob Node.js, Bun, Envoy oder Python mit Brotli-Unterstützung in Ihren Systemen läuft. Mit Versionsnummer. Imperva weist darauf hin, dass Paketlisten gebündelte Laufzeiten in Container-Images oft übersehen, deshalb lohnt die Prüfung direkt im laufenden Image.
Aktualisieren und neu ausrollen
Ein Update der Laufzeit genügt erst, wenn Images neu gebaut, Anwendungen neu ausgerollt und Dienste neu gestartet sind. Bei Linux-Distributionen kann die Korrektur auch zurückportiert sein, ohne dass sich die Versionsnummer ändert. Klarheit schaffen dann nur die Sicherheitshinweise des jeweiligen Anbieters, in denen die CVE-Nummer mit dem korrigierten Paket aufgeführt ist.
Übergangsweise abschotten
Bis alles aktualisiert ist, können Proxy, Load Balancer oder Middleware Anfragen mit dem Header Content-Encoding „br“ abweisen. Für abgehende Anfragen reicht es nicht, „br“ aus dem Accept-Encoding-Header zu streichen, denn ein bösartiger Server kann trotzdem Brotli schicken. Für fetch() in Node.js gibt es keinen Standardschalter, der das Entpacken abschaltet. Hier hilft nur das Update. Imperva hat zudem WAF-Regeln ergänzt, ausdrücklich als Übergangslösung.
Woran sich ein Angriff erkennen lässt
Kaum. Imperva nennt zwar zwei Hinweise, die bei der Priorisierung helfen können: unerwartete Abstürze von Prozessen während des Entpackens und gehäufte Fehlermeldungen des Decoders in den Logs. Beides ist aber kein verlässliches Zeichen für einen Angriff, denn auch fehlerhafte, harmlose Daten oder Netzwerkprobleme können solche Spuren hinterlassen. Wer Logs zentral sammelt, sollte trotzdem für die Zeit bis zum Update gezielt nach solchen Mustern suchen und Auffälligkeiten mit Datum und betroffenem System festhalten, damit sich im Ernstfall nachvollziehen lässt, ab wann ein Server angreifbar war.
Warum das auch eine Pflichtfrage ist
Schnelles Patchen ist für viele Firmen inzwischen auch eine Frage der Compliance. Wer unter die NIS2-Richtlinie fällt, muss ein geordnetes Schwachstellenmanagement nachweisen können. Ein Beleg dafür: die dokumentierte Reaktion auf Node2Shell. Dass auch große Händler ins Visier geraten, zeigte der Cyberangriff mit Datenleck bei Lidl. Wie arbeitsteilig Angreifer inzwischen organisiert sind, wurde beim Schlag von BKA und US-Behörden gegen einen Phishing-Dienst mit mehr als 200 Servern sichtbar. Mit öffentlichem Proof of Concept steigt die Wahrscheinlichkeit, dass Angreifer Node2Shell bald gezielt einsetzen.
