Node2Shell: Die Node.js-Sicherheitslücke schließen und im Audit belegen

Das Wichtigste in Kürze

• Node2Shell (CVE-2026-111497) ist ein Out-of-Bounds-Write im Brotli-Decoder von Node.js, erreichbar über das Modul node:zlib. Angreifer können damit ohne Anmeldung aus der Ferne einen Absturz auslösen, Speicherinhalte auslesen oder Code ausführen. Node.js stuft die Lücke als "High" ein; berichtet wird zudem ein CVSS-Wert von 9.2.
• Behoben ist Node2Shell seit dem 21. Oktober 2026 in Node.js 26.12.1, 24.22.1 und 22.23.4. Für Node.js 25, 23, 20 und ältere Versionen gibt es keinen Fix, weil diese Versionszweige End of Life sind.
• Die Ursache liegt in Googles Brotli-Bibliothek, korrigiert in den Versionen 1.2.1, 1.1.1 und 1.0.10. Deshalb sind auch Bun, .NET, Envoy, Istio, Python-HTTP-Clients, FFmpeg, Apache Arrow und ClickHouse betroffen.
• Exploit-Code ist auf GitHub öffentlich, ELLIO hat am 26. Oktober 2026 Angriffsversuche gemeldet und die US-Behörde CISA führt die Lücke seit Ende Oktober als aktiv ausgenutzt. US-Bundesbehörden müssen bis zum 10. November 2026 patchen.
• Die Schwachstelle allein ist unter NIS2 kein meldepflichtiger Vorfall. In einem ISMS nach ISO 27001 fällt die Reaktion unter Control A.8.8; im nächsten Audit sollten Sie Inventar, Entscheidung, Patch-Datum und Nachweis vorlegen können.

‍

Am 21. Oktober 2026 hat das Node.js-Projekt Sicherheitsupdates für eine Lücke veröffentlicht, die unter dem Namen Node2Shell bekannt geworden ist. Die Node.js-Sicherheitslücke steckt nicht in einem npm-Paket, sondern im Brotli-Decoder, den jede Node.js-Installation mitbringt. Betroffen sind damit Webanwendungen und APIs ebenso wie Build-Server, CI-Runner und Container-Images, in denen Node.js läuft.

Nach PHP2Shell ist Node2Shell innerhalb weniger Wochen die zweite Lücke dieser Art, die eine weit verbreitete Laufzeitumgebung direkt trifft. Anders als bei PHP2Shell reicht der Fehler diesmal weit über ein einzelnes Projekt hinaus, weil er in einer Bibliothek liegt, die zahlreiche andere Produkte ebenfalls verwenden.

Dieser Artikel richtet sich an ISMS-Verantwortliche, IT-Leitungen und Compliance-Teams, nicht an Entwickler. Er erklärt, was die Lücke ist, wie Sie herausfinden, ob Sie direkt oder über Dienstleister betroffen sind, und was Node2Shell für Unternehmen bedeutet, die nach ISO 27001 zertifiziert sind oder unter NIS2 fallen.

Was ist Node2Shell?

Node2Shell ist eine Schwachstelle im Brotli-Decoder von Node.js. Brotli ist ein Kompressionsverfahren, das Webserver und Browser nutzen, um Daten kleiner zu übertragen. Verarbeitet eine Anwendung manipulierte Brotli-Daten über das eingebaute Modul node:zlib, schreibt der Decoder über das Ende eines internen Puffers hinaus. Fachleute nennen das einen Out-of-Bounds-Write.

Die Folgen reichen vom Absturz des Prozesses über das Auslesen von Speicherinhalten bis zur Ausführung von Schadcode, also Remote Code Execution. Angreifer brauchen dafür weder Zugangsdaten noch Zugriff auf das interne Netz. Node.js bewertet die Lücke mit dem Schweregrad "High". In Berichten, etwa bei GCN, wird außerdem ein CVSS-Wert von 9.2 genannt, ohne dass klar ist, wer diesen Wert vergeben hat.

Warum reicht die Lücke über Node.js hinaus?

Die eigentliche Ursache liegt nicht in Node.js, sondern in Brotli, einer Open-Source-Bibliothek von Google. Node.js bündelt diese Bibliothek und das tun auch viele andere Produkte. Fachmedien sprechen deshalb auch von Brotli2Shell. Laut Help Net Security sind neben Node.js unter anderem Bun, .NET, Envoy, Istio, Python-HTTP-Clients, FFmpeg, Apache Arrow und ClickHouse betroffen.

Bemerkenswert ist die Vorgeschichte. Die Korrektur in der Brotli-Bibliothek wurde bereits am 27. Februar 2026 eingespielt, allerdings ohne neues Release und ohne Sicherheitshinweis. Acht Monate lang war die Änderung öffentlich einsehbar, bevor die korrigierten Brotli-Versionen 1.2.1, 1.1.1 und 1.0.10 erschienen. Wer Abhängigkeiten nur bei offiziellen Releases aktualisiert, hatte in dieser Zeit keine Chance, den Fix zu übernehmen.

Wie hat sich die Lage entwickelt?

Am 21. Oktober 2026 hat Node.js die Lücke veröffentlicht und am selben Tag korrigierte Versionen bereitgestellt. Kurz darauf tauchte Proof-of-Concept-Code auf GitHub auf. Am 26. Oktober meldete das Threat-Intelligence-Unternehmen ELLIO Angriffsversuche, die seine Sensoren im Internet erfasst hatten.

Ende Oktober hat die US-Cybersicherheitsbehörde CISA Node2Shell in ihren Katalog aktiv ausgenutzter Schwachstellen aufgenommen. US-Bundesbehörden müssen die Lücke bis zum 10. November 2026 schließen. Für europäische Unternehmen ist diese Frist rechtlich nicht bindend. Sie taugt aber als äußerste Grenze: Was danach noch ungepatcht ist, lässt sich gegenüber einem Auditor kaum noch begründen.

Welche Node.js-Versionen sind betroffen?

Betroffen sind die Node.js-Versionszweige 22, 24 und 26 vor den Sicherheitsreleases vom 21. Oktober 2026 sowie alle Versionszweige, die End of Life sind. Für alle anderen Produkte mit Brotli-Decoder entscheidet die Version der mitgelieferten Bibliothek.

Die Versionen in der Tabelle sind die Mindeststände. Node.js hat für den 11. November 2026 weitere Sicherheitsreleases angekündigt. Installieren Sie deshalb jeweils das neueste Patch-Release Ihres Versionszweigs, nicht nur die oben genannte Version. Die vollständigen Details stehen im Sicherheitshinweis des Node.js-Projekts.

Ein häufiger Fehlschluss lautet: "Wir setzen kein Node.js ein, also betrifft uns das nicht." Die Brotli-Lücke steckt auch in Produkten, bei denen niemand an Node.js denkt. Ein Beispiel sind die Windows-Pakete von PHP, die Brotli mitbringen und deshalb am 26. Oktober neu gebaut wurden. Was das für PHP-Server bedeutet, beschreibt unser Beitrag zu PHP2Shell. Auch Linux-Distributionen liefern Brotli als eigenes Paket aus, das Sie über die normalen System-Updates aktualisieren.

Was sollten Unternehmen jetzt tun?

Die wichtigste Aufgabe ist ein vollständiger Überblick darüber, wo in Ihrem Unternehmen Node.js und andere Software mit Brotli-Decoder laufen. Node.js steckt oft an Stellen, die in keinem Server-Inventar auftauchen: in Build-Pipelines, in Container-Images und in Tools, die Entwicklungsteams selbst betreiben.

1. Inventar erstellen (Tag 1, IT-Betrieb und Entwicklung). Erfassen Sie jede Node.js-Laufzeitumgebung mit ihrer Version: Server, Container-Images, CI-Runner und Build-Server, interne Tools und Staging-Umgebungen. Prüfen Sie zusätzlich die übrigen Produkte aus der Tabelle, etwa Envoy oder Istio im Service-Mesh.
2. Patchen (Tag 1 bis 2, Entwicklung). Aktualisieren Sie mindestens auf 22.23.4, 24.22.1 oder 26.12.1, besser auf das neueste Patch-Release. Für Bun gilt mindestens 1.4.4.
3. Images neu bauen und Prozesse neu starten (Tag 2, DevOps). Ein Update wirkt erst, wenn der laufende Prozess die neue Version nutzt. Container, die auf ein festes Image-Tag mit alter Node.js-Version verweisen, bleiben verwundbar, bis Sie das Image neu bauen und ausrollen.
4. End-of-Life-Versionen ablösen (Woche 1, IT-Leitung). Was noch auf Node.js 20, 23 oder 25 läuft, erhält keinen Fix mehr. Planen Sie den Wechsel auf Version 22, 24 oder 26 und halten Sie fest, bis wann er erfolgt.
5. Übergangsweise Brotli-Anfragen ablehnen (sofort, Netzwerk oder Betrieb). Bis zum Patch können Sie am Reverse Proxy oder Load Balancer Anfragen mit dem Header "Content-Encoding: br" abweisen. Diese Maßnahme schützt nur vor eingehenden Anfragen. Brotli-komprimierte Antworten, die Ihre Anwendung selbst von anderen Servern abruft, deckt sie nicht ab.
6. Lieferanten befragen (Woche 1, ISB und Einkauf). Fragen Sie SaaS-Anbieter, Hoster und Agenturen schriftlich, ob ihre Systeme betroffen waren und bis wann sie gepatcht haben. Das gilt auch für verwaltete Cloud-Dienste, bei denen der Anbieter die Laufzeitumgebung aktualisiert.
7. Dokumentieren und bei Verdacht eskalieren (laufend, ISB oder CISO). Halten Sie fest, wann Sie von der Lücke erfahren haben, welche Systeme betroffen waren und wann Sie gepatcht haben. Gibt es Hinweise auf eine Kompromittierung, etwa ungeklärte Abstürze von Node.js-Prozessen seit dem 21. Oktober, greift Ihr Incident-Response-Prozess.

Der häufigste Irrtum nach einem Patch-Tag lautet: "Das Paket ist aktualisiert, also sind wir fertig." Auf dem Server liegt dann zwar die neue Node.js-Version, aber der alte Prozess läuft weiter, bis er neu startet. Ebenso läuft in Kubernetes oft noch ein Pod mit dem alten Image, während das neue längst in der Registry liegt. Fragen Sie deshalb nicht nur "Ist gepatcht?", sondern "Welche Version läuft gerade?".

Was verlangt NIS2 bei einer Lücke wie Node2Shell?

Unter NIS2 ist der Umgang mit Schwachstellen eine ausdrückliche Pflicht. Artikel 21 Absatz 2 der Richtlinie verlangt Maßnahmen zur Sicherheit der Lieferkette (Buchstabe d) und zur Sicherheit bei Erwerb, Entwicklung und Wartung von Systemen, einschließlich der Behandlung von Schwachstellen (Buchstabe e). In Deutschland stehen beide Pflichten in § 30 BSI-Gesetz, das mit dem NIS2-Umsetzungsgesetz seit dem 6. Dezember 2025 neu gefasst ist.

Wann greift die Meldepflicht?

Eine Schwachstelle allein ist kein Sicherheitsvorfall. Dass Ihre Systeme eine verwundbare Node.js-Version hatten, löst keine Meldung an das BSI aus. Meldepflichtig ist erst ein erheblicher Sicherheitsvorfall, etwa wenn Angreifer über Node2Shell Daten abgegriffen oder einen Dienst lahmgelegt haben.

Tritt dieser Fall ein, gelten in Deutschland die Fristen aus § 32 BSI-Gesetz: eine Erstmeldung spätestens 24 Stunden, nachdem Sie von dem erheblichen Sicherheitsvorfall Kenntnis erlangt haben, eine Meldung mit erster Bewertung innerhalb von 72 Stunden und eine Abschlussmeldung spätestens einen Monat nach dieser Meldung. Die Meldungen gehen an die gemeinsame Meldestelle von BSI und BBK.

Was gilt für Dienstleister und Kunden in der Lieferkette?

Node2Shell ist ein typischer Lieferkettenfall. Viele Unternehmen betreiben selbst kaum Node.js, nutzen aber SaaS-Produkte, Agentur-Websites und Hosting-Dienste, die darauf laufen. Für diese Dienste können Sie nicht selbst patchen, Sie müssen den Status erfragen und die Antwort dokumentieren.

Umgekehrt gilt das auch für Sie. Fallen Ihre Kunden unter NIS2, werden deren Einkaufs- und Sicherheitsteams in den kommenden Wochen fragen, wie Sie auf Node2Shell reagiert haben. Wer dann Versionen, Patch-Daten und den Stand der Lieferanten vorlegen kann, beantwortet den Fragebogen in einem Arbeitsschritt. Welche Fragen und Vertragsklauseln Ihnen dabei begegnen, auch wenn Ihr Unternehmen selbst nicht betroffen ist, beschreibt unser Beitrag zu NIS2 in der Lieferkette.

Wie behandeln Sie Node2Shell im ISMS nach ISO 27001?

In einem ISMS nach ISO 27001:2022 ist Node2Shell ein Testfall für mehrere Controls aus Anhang A. Im Mittelpunkt steht A.8.8, das Management technischer Schwachstellen: Sie müssen Informationen über Schwachstellen rechtzeitig erhalten, Ihre Gefährdung bewerten und angemessene Maßnahmen ergreifen.

Daneben greifen weitere Controls. A.5.9 verlangt ein Inventar der Werte, ohne das Sie nicht wissen, wo überall Node.js läuft. A.8.9 regelt das Konfigurationsmanagement, also auch die Frage, welche Image-Version in Produktion läuft. A.5.19 bis A.5.22 decken die Lieferantenbeziehungen ab, von der Vertragsgestaltung bis zur Überwachung der Dienstleister. A.5.24 bis A.5.26 regeln das Vorfallmanagement von der Planung über die Bewertung bis zur Reaktion. Wie diese ISO-27001-Controls zusammenspielen, erklären wir in einem eigenen Beitrag.

Was wollen Auditoren sehen?

Im nächsten Überwachungsaudit wird die Frage kommen, wie Ihr Unternehmen auf Node2Shell reagiert hat. Ein Auditor erwartet vier Dinge: ein Inventar der betroffenen Systeme, eine dokumentierte Entscheidung zur Bewertung, das Datum des Patches je System und einen Nachweis, dass die neue Version tatsächlich läuft. Für Systeme, die Sie nicht sofort patchen konnten, gehört eine begründete Ausnahme mit Frist dazu.

Ein Beispiel: Ein SaaS-Unternehmen mit 40 Beschäftigten betreibt drei Dienste auf Node.js 22 in neun Container-Images. Die CI-Runner laufen noch auf Node.js 20, die Marketing-Website betreut eine Agentur. Das Team baut die Images am Tag der Veröffentlichung neu und stellt die CI-Runner in der folgenden Woche auf Node.js 24 um, weil Version 20 keinen Fix mehr erhält. Die Agentur bestätigt den Patch ihres Hosters per E-Mail. Hängen Tickets mit Zeitstempeln und die Bestätigung der Agentur am Schwachstellenprozess, ist die Frage des Auditors schnell beantwortet.

End-of-Life-Versionen sind dabei der Punkt, an dem Audits häufig hängen bleiben. Ein Versionszweig ohne Support ist kein einmaliges Problem dieser Lücke, sondern ein dauerhaftes Risiko, das Sie im Risikoregister führen sollten. Wie Sie mit einem festen Support-Ende umgehen, zeigt unser Beitrag zum PHP 8.2 End of Life am Beispiel einer anderen Laufzeitumgebung.

Was gilt nach DSGVO, wenn personenbezogene Daten betroffen sind?

Unabhängig von NIS2 gilt die DSGVO. Haben Angreifer über Node2Shell auf Kundendaten, Zugangsdaten oder andere personenbezogene Daten zugegriffen, liegt eine Verletzung des Schutzes personenbezogener Daten vor. Nach Artikel 33 DSGVO ist sie innerhalb von 72 Stunden an die zuständige Datenschutzaufsicht zu melden, sofern ein Risiko für die Betroffenen besteht.

Weil die Lücke auch das Auslesen von Speicherinhalten erlaubt, sollte Ihr Datenschutzbeauftragter früh eingebunden sein, nicht erst nach Abschluss der technischen Analyse. Wann eine Meldung Pflicht ist und was in der ersten Stunde passieren sollte, beschreibt unser Beitrag zur Meldepflicht bei Datenschutzvorfällen.

Wie lässt sich die Behebung automatisch nachweisen?

Nach einer Lücke wie Node2Shell müssen Sie die Behebung nicht nur umsetzen, sondern im Audit auch belegen. Aikido Security erkennt nach eigenen Angaben die betroffenen Node.js-Versionen in Repositories und Container-Images und zeigt im Dashboard, welche Dienste noch eine verwundbare Laufzeitumgebung nutzen. Damit ist der erste Schritt, das Inventar, für den eigenen Code bereits erledigt.

Kertos liest über die Integration von Aikido und Kertos diese Befunde und die Fristen, die Sie für ihre Behebung gesetzt haben, täglich aus. Ist keine Frist überschritten, gilt die Prüfung als bestanden und Kertos legt das Ergebnis als Nachweis für die passenden Anforderungen aus ISO 27001, NIS2 und SOC 2 ab. Die Verbindung ist ausschließlich lesend und verändert in Aikido nichts.

Für Ihr Audit bedeutet das: Der Nachweis, wann eine Schwachstelle gefunden und wann sie behoben wurde, entsteht dort, wo die Arbeit passiert. Die zertifizierten Experten von Kertos unterstützen Sie dabei, Ihren Schwachstellen-, Lieferanten- und Vorfallprozess so aufzusetzen, dass er auch die nächste kritische Lücke trägt. Wenn Sie sehen möchten, wie das in Ihrer Umgebung aussieht, vereinbaren Sie eine Demo.

Häufig gestellte Fragen

Was ist Node2Shell?

Node2Shell ist der Name für CVE-2026-111497, einen Out-of-Bounds-Write im Brotli-Decoder von Node.js. Angreifer können damit ohne Anmeldung aus der Ferne einen Absturz auslösen, Speicherinhalte auslesen oder Code ausführen. Node.js hat am 21. Oktober 2026 korrigierte Versionen veröffentlicht.

Bin ich von CVE-2026-111497 betroffen?

Betroffen sind Sie, wenn Sie Node.js 22, 24 oder 26 vor den Versionen 22.23.4, 24.22.1 und 26.12.1 einsetzen oder einen Versionszweig, der End of Life ist. Weil die Ursache in Googles Brotli-Bibliothek liegt, können auch Bun, .NET, Envoy, Istio, Python-HTTP-Clients, FFmpeg, Apache Arrow und ClickHouse betroffen sein. Prüfen Sie außerdem, ob Ihre SaaS-Anbieter und Hoster gepatcht haben.

Welche Node.js-Version ist sicher?

Sicher vor Node2Shell sind mindestens Node.js 26.12.1, 24.22.1 und 22.23.4. Node.js hat für den 11. November 2026 weitere Sicherheitsreleases angekündigt, deshalb sollten Sie jeweils das neueste Patch-Release Ihres Versionszweigs einsetzen. Für Bun gilt mindestens Version 1.4.4.

Was tun, wenn wir Node.js 20 noch einsetzen?

Node.js 20 ist End of Life und erhält keinen Fix für Node2Shell, ebenso wie die Versionen 23 und 25. Wechseln Sie auf Node.js 22, 24 oder 26 und blockieren Sie bis dahin am Proxy Anfragen mit "Content-Encoding: br". Was Sie nicht sofort umstellen können, sollten Sie als Ausnahme mit Frist im Risikoregister dokumentieren.

Muss ich Node2Shell nach NIS2 oder DSGVO melden?

Nicht allein deshalb, weil Ihre Systeme die Schwachstelle hatten. Nach NIS2 ist erst ein erheblicher Sicherheitsvorfall meldepflichtig: Erstmeldung innerhalb von 24 Stunden, Meldung mit erster Bewertung innerhalb von 72 Stunden und Abschlussmeldung spätestens einen Monat danach. Sind personenbezogene Daten betroffen, gilt zusätzlich die 72-Stunden-Frist aus Artikel 33 DSGVO.