Node2Shell: Die Node.js-Sicherheitslücke, die auch Self-Hosting-Tools wie n8n betrifft

Wer in den vergangenen Tagen eine Website, einen Onlineshop oder ein selbst gehostetes Automatisierungstool betrieben hat, ist vermutlich schon über die PHP-Sicherheitslücke „PHP2Shell" gestolpert. Parallel dazu, fast unbemerkt neben der großen PHP-Meldung, hat sich eine zweite Lücke entwickelt, die eine deutlich breitere Softwarelandschaft betrifft: ein Fehler im Brotli-Kompressionsdecoder, der nicht nur in Node.js steckt, sondern in praktisch jeder Sprache und jedem Produkt, das Brotli-Daten entpackt. Für Unternehmen, die Node.js-basierte Software selbst betreiben – etwa die in diesem Blog mehrfach besprochene Automatisierungsplattform n8n – ist das keine akademische Randnotiz, sondern ein konkreter Patch-Auftrag.

Was die Lücke ausmacht

Am 21. Oktober 2026 hat das Node.js-Projekt Sicherheitsupdates (öffnet in neuem Tab) für die Versionslinien 22.x, 24.x und 26.x veröffentlicht. Die schwerwiegendste der insgesamt zehn behobenen Schwachstellen trägt die Kennung CVE-2026-111497 und betrifft den im Node.js-Binary mitgelieferten Decoder für das Kompressionsformat Brotli: Ein fehlerhaft behandelter Blockwechsel im Datenstrom lässt den Decoder einen internen Acht-Byte-Puffer über seine Grenzen hinaus beschreiben. Laut Node.js-Projekt (öffnet in neuem Tab) kann ein Angreifer, der Brotli-Daten liefert, die eine Anwendung über node:zlib dekomprimiert, damit Prozessspeicher beschädigen – mit möglicher Folge: Absturz, Auslesen von Speicherinhalten oder Remote-Codeausführung.

Was die Lücke besonders macht: Sie steckt nicht im Node.js-eigenen Code, sondern in der von Google entwickelten Brotli-Bibliothek selbst, die zahlreiche Laufzeitumgebungen und Programmiersprachen einbinden. Laut heise online (öffnet in neuem Tab) betrifft der Fehler Brotli-Versionen 1.0.3 bis 1.2.0 auf allen Plattformen und erreicht laut der zugrunde liegenden Schwachstellen-Datenbank einen CVSS4-Basiswert von 9,2 von 10 möglichen Punkten – damit gilt sie als kritisch. Google hat die Lücke in den Brotli-Versionen 1.0.10, 1.1.1 und 1.2.1 geschlossen.

Neben Node.js (gefixt in 26.12.1, 24.22.1 und 22.23.4) sind laut heise unter anderem Bun, .NET, Python-Bibliotheken wie Brotli und brotlicffi sowie Software betroffen, die Brotli über C-Bindings einbindet – etwa Java-JNI-Wrapper, PHP- oder Ruby-Erweiterungen und Go-cgo-Bindings. Eine gewisse Entwarnung gibt es laut heise für Apache und Nginx, die in Standardkonfiguration kein Brotli dekodieren.

Warum das mehr Unternehmen betrifft als „nur Entwickler"

Node.js ist längst keine reine Entwicklersprache mehr, sondern steckt als Laufzeitumgebung in einer Vielzahl von Werkzeugen, die auch im Mittelstand produktiv eingesetzt werden – häufig, ohne dass der Betrieb das bewusst als „Node.js-Anwendung" wahrnimmt. Ein konkretes Beispiel, das Leser dieses Blogs betreffen dürfte: n8n, die selbst gehostete Workflow-Automatisierung, auf der in einem früheren Beitrag das eigene Docker-Compose-Setup beschrieben wurde.

Laut Diskussion in der n8n-Community (öffnet in neuem Tab) lief die stabile n8n-Version 2.44.5 am 21. und 22. Oktober noch auf Node.js 26.10.0 – also auf einer vor der Lücke ungepatchten Laufzeit. Ein n8n-Supportmitarbeiter bestätigte in demselben Thread, dass erst die am 22. Oktober veröffentlichte Version 2.44.6 (ebenso die Beta-Version 2.45.2) auf das gepatchte Node.js 26.12.1 aktualisiert wurde – und riet ausdrücklich zum Upgrade, da keine vertrauenswürdige Übergangslösung für die ungepatchte Laufzeit existiere. Wer n8n selbst hostet und beim letzten automatischen Update nicht genau hingeschaut hat, läuft also möglicherweise noch auf einer verwundbaren Version.

Das Muster ist nicht auf n8n beschränkt: Jede selbst gehostete Software, die auf Node.js basiert und in irgendeiner Form komprimierte Daten aus dem Netz entgegennimmt – etwa über eingehende HTTP-Anfragen oder über die in Node.js eingebaute fetch()-Funktion, die Antworten automatisch dekomprimiert – ist laut Akamai-Analyse (öffnet in neuem Tab) potenziell betroffen. Laut derselben Analyse liefen zum Zeitpunkt der Veröffentlichung 61 Prozent der von Akamai beobachteten Netzwerke noch auf einer verwundbaren Node.js-Version – ein Hinweis darauf, wie langsam Patches in der Praxis tatsächlich ausgerollt werden, auch wenn sich diese Momentaufnahme nicht unmittelbar auf deutsche Mittelstandsunternehmen übertragen lässt.

Wie real das Risiko bereits ist

Eine theoretische Schwachstelle ist das Problem schon lange nicht mehr. Der Sicherheitsfirma Imperva gelang laut heise online (öffnet in neuem Tab) bereits am Folgetag der Veröffentlichung Codeausführung auf einem unveränderten, offiziellen Node.js-24.22.0-Docker-Image – wenn auch erst nach mehreren Versuchen. Entdeckt wurde die Lücke laut Aikido Security (öffnet in neuem Tab) bereits im Februar 2026 vom OpenAI-Sicherheitsteam; die damalige Korrektur im Brotli-Quellcode wurde jedoch nicht als sicherheitsrelevant eingestuft, sodass acht Monate vergingen, bis eine gepatchte Version veröffentlicht wurde.

Zum aktuellen Stand gibt es laut Sysdig (öffnet in neuem Tab) keine bestätigten Angriffe in freier Wildbahn, und die Lücke steht nicht im Known-Exploited-Vulnerabilities-Katalog der US-Behörde CISA. Proof-of-Concept-Exploits sind jedoch öffentlich verfügbar, und mit „Node2Shell" und „Broccoli2Shell" kursieren bereits zwei eingängige Namen für die Lücke – ein Muster, das bei vergleichbaren Schwachstellen in der Vergangenheit regelmäßig der Beschleuniger für breit angelegte automatisierte Angriffswellen war.

Was Sie jetzt konkret prüfen sollten

1. Node.js-Version ermitteln. Auf jedem Server mit Node.js-Laufzeit zeigt node --version die aktive Version. Betroffen sind laut Node.js-Projekt (öffnet in neuem Tab) alle 22.x-, 24.x- und 26.x-Versionen vor 22.23.4, 24.22.1 beziehungsweise 26.12.1. Ältere, bereits ausgelaufene Versionslinien wie 18.x oder 20.x erhalten keinen offiziellen Fix mehr und gelten laut Node.js-Projekt grundsätzlich als betroffen.

2. Container-Images neu bauen, nicht nur neu starten. Wer Node.js-Anwendungen in Docker betreibt, reicht ein bloßer Neustart nicht: Ein gecachtes Image mit einem floating Tag wie node:24 bleibt auf der alten Version, solange kein frisches docker pull erfolgt. Nach dem Update lohnt sich die Kontrolle direkt im laufenden Container mit node --version.

3. Self-Hosting-Tools gezielt prüfen. Bei Software wie n8n reicht die Node.js-Version des Basis-Images nicht aus – die in der Community-Diskussion zitierten Versionsnummern zeigen, dass selbst Anbieter mit aktivem Sicherheitsteam ein bis zwei Tage brauchten, bis das Docker-Image auf die gepatchte Laufzeit umgestellt war. Ein Blick in die eigene docker-compose.yml beziehungsweise ein docker run --rm --entrypoint node <image> -v auf dem verwendeten Image gibt Klarheit.

4. Reverse Proxies und Gateways nicht vergessen. Laut heise online (öffnet in neuem Tab) sind auch Software-Komponenten betroffen, die Brotli über C-Bindings einsetzen, etwa bestimmte Java- oder PHP-Erweiterungen. Wer Produkte von Drittanbietern im Einsatz hat, sollte deren Sicherheitsmitteilungen nach Hinweisen auf CVE-2026-111497 durchsuchen, statt sich allein auf die eigene Node.js-Installation zu verlassen.

Fazit

Node2Shell ist kein Einzelfall, sondern Teil eines inzwischen vertrauten Musters: Eine Lücke in einer tief eingebetteten Bibliothek betrifft nicht nur die Software, in der sie entdeckt wurde, sondern eine ganze Kette von Produkten, die diese Bibliothek mitbringen, ohne dass Betreiber das im Alltag auf dem Schirm haben. Für Unternehmen, die – wie viele unserer Leser – selbst gehostete Automatisierung, interne Tools oder Webanwendungen auf Node.js-Basis betreiben, heißt das: Die Verantwortung für das Patchen endet nicht bei der eigenen Anwendung, sondern reicht bis in die Laufzeitumgebung jedes einzelnen Containers hinein. Ein kurzer Versionscheck aller produktiv laufenden Node.js-Instanzen ist in den meisten Umgebungen in wenigen Minuten erledigt – und angesichts der CVSS-Einstufung 9,2 eine, die sich lohnt, bevor aus der PoC-Lücke ein PoC-Angriff wird.