Wissen · IT-Sicherheit
Node.js-Sicherheitslücken: Warum ein Paket-Update allein nicht reicht
Das Node.js-Projekt hat am 21. Oktober 2026 zehn Sicherheitslücken geschlossen, vier davon mit hoher Schwere. Die gefährlichste kann es Angreifern ermöglichen, Programmcode auf dem Server auszuführen. Dieser Beitrag erklärt, wo Node.js im Unternehmen steckt, wer zuständig ist und warum das übliche Update der Anwendung hier nicht genügt.
Worum es geht
Node.js ist eine Laufzeitumgebung, mit der Programme in JavaScript auf einem Server laufen. Viele moderne Webanwendungen bauen darauf auf: Kundenportale, Buchungssysteme, Schnittstellen zwischen Programmen und interne Werkzeuge, die eine Agentur oder ein Softwarepartner für Ihr Unternehmen entwickelt hat.
Am 21. Oktober 2026 hat das Node.js-Projekt Sicherheitsupdates für alle unterstützten Versionen veröffentlicht. Geschlossen wurden zehn Schwachstellen mit eigener CVE-Nummer (der weltweit einheitlichen Kennung für Sicherheitslücken), vier davon mit hoher Schwere. Einen offiziellen Workaround gibt es nicht. Wirksam ist nur das Update der Laufzeitumgebung.
Node2Shell: die gefährlichste Lücke
Die schwerste Schwachstelle trägt die Kennung CVE-2026-111497 und wird von Sicherheitsforschern als „Node2Shell" bezeichnet. Sie steckt in dem Teil von Node.js, der mit dem Verfahren Brotli komprimierte Daten entpackt. Brotli ist ein gängiges Kompressionsverfahren, mit dem Webseiten und Daten schneller übertragen werden.
Verarbeitet eine Anwendung präparierte, komprimierte Daten, kann ein Angreifer im ungünstigsten Fall eigenen Programmcode ausführen – mit den Rechten, mit denen die Anwendung läuft. Tückisch daran: Die Anwendung muss Brotli nicht bewusst verwenden. Es genügt, dass sie komprimierte Daten von außen annimmt oder weiterreicht, etwa bei Datei-Uploads, Schnittstellen zu anderen Diensten oder automatischen Benachrichtigungen zwischen Systemen (Webhooks).
Nach aktuellem Stand gibt es keine Berichte über laufende Angriffe. Das ändert sich bei so bekannten Lücken erfahrungsgemäß schnell, sobald Details öffentlich sind.
Die weiteren Lücken
Drei weitere Schwachstellen mit hoher Schwere betreffen die Prüfung verschlüsselter Verbindungen und die Namensauflösung:
- CVE-2026-106069 und CVE-2026-105483: Bei Verbindungen zu IP-Adressen in ungewöhnlicher Schreibweise kann die Prüfung des Zertifikats umgangen werden. Eine Anwendung könnte dann glauben, mit dem richtigen Server zu sprechen, obwohl es ein anderer ist.
- CVE-2026-105482: Bei manipulierten Rechnernamen kann der geprüfte Name von dem abweichen, der tatsächlich abgefragt wird.
Diese Lücken sind auch für Dienste relevant, die selbst nicht direkt aus dem Internet erreichbar sind – etwa wenn sie Daten bei externen Diensten abrufen oder Adressen verarbeiten, die Benutzer eingeben. Die übrigen sechs Lücken betreffen unter anderem HTTP-Verbindungen, Kryptografie und Komprimierung und können zum Beispiel Ausfälle oder das ungewollte Preisgeben von Daten verursachen.
Welche Versionen betroffen sind
Behoben sind die Lücken ab folgenden Versionen:
- Node.js 22: ab Version 22.23.4
- Node.js 24: ab Version 24.22.1
- Node.js 26: ab Version 26.12.1
Node.js 25 erhält in dieser Runde kein Update. Node.js 20 und ältere Versionen (18, 16, 14, 12) werden vom Projekt nicht mehr unterstützt und bekommen keine offizielle Korrektur. Diese Systeme müssen auf eine unterstützte Version umgestellt werden; bei aus dem Internet erreichbaren Anwendungen ist das kein Projekt für „irgendwann", sondern dringend.
Warum das übliche Update nicht genügt
Bei Node.js-Anwendungen gibt es zwei Ebenen: die Anwendung mit ihren Programmbausteinen und darunter die Laufzeitumgebung Node.js selbst. Viele Entwicklerteams prüfen regelmäßig die Programmbausteine, etwa mit dem Werkzeug npm audit. Die aktuellen Lücken liegen aber in der Laufzeitumgebung. Diese Prüfungen finden sie nicht, und ein Update der Anwendung schließt sie nicht.
Dazu kommt: Eine bereits laufende Anwendung verwendet die alte Version weiter, bis sie neu gestartet wird. Läuft die Anwendung in einem Container – einer abgeschlossenen Software-Umgebung, wie sie heute häufig eingesetzt wird –, muss dieser Container neu gebaut und neu gestartet werden. Ein aktualisiertes Paket auf dem Server allein ändert daran nichts.
Wer ist bei uns zuständig?
Gerade bei Node.js ist die Zuständigkeit oft unklar, weil Entwicklung und Betrieb getrennt sind:
- Die Agentur oder der Softwarepartner hat die Anwendung gebaut und legt fest, auf welcher Node.js-Version sie läuft – besonders bei Containern.
- Der Betreiber des Servers – Ihre IT, Ihr IT-Dienstleister oder der Anbieter eines Managed Servers – spielt Updates auf dem System ein.
- Bei Cloud-Plattformen hängt es vom Angebot ab, ob die Plattform die Laufzeitumgebung selbst aktualisiert.
Eine kurze schriftliche Rückfrage an alle Beteiligten schafft Klarheit: „Welche Node.js-Version läuft tatsächlich in unseren Anwendungen, und ist das Update vom 21. Oktober aktiv?" Wichtig ist das Wort tatsächlich – entscheidend ist die laufende Version, nicht die installierte.
Was jetzt zu tun ist
Für die Geschäftsführung genügen fünf Schritte:
- Bestandsaufnahme: Welche Anwendungen, Schnittstellen und internen Werkzeuge laufen auf Node.js?
- Zuständigkeit klären: Wer aktualisiert die Laufzeitumgebung, wer baut Container neu?
- Update einspielen und Dienste neu starten lassen.
- Laufende Version schriftlich bestätigen lassen – nicht nur die installierte.
- Alte Versionen ersetzen: Anwendungen auf Node.js 20 oder älter rasch auf eine unterstützte Version umstellen.
Für Ihre IT-Verantwortlichen in Kurzform: Version mit node -v prüfen, auf Hosts, in Containern, in Build-Umgebungen und bei Serverless-Diensten. Nach dem Update der Pakete alle Node-Prozesse neu starten, Container-Images vollständig neu bauen und die Version danach im laufenden Container prüfen. Anschließend auf Abstürze, unerwartete Prozesse, ungewöhnliche Netzwerkverbindungen und Speicherauffälligkeiten achten. Bei Verdacht: Instanz isolieren, Protokolle sichern und Zugangsdaten erneuern.
Warum ein fester Update-Prozess entscheidend ist
Die Oktober-Updates zeigen ein Muster, das bei modernen Webanwendungen häufig ist: Sicherheitslücken stecken tief in der Laufzeitumgebung, während die üblichen Prüfwerkzeuge nur die Anwendung selbst sehen. Wer nicht weiß, welche Version wo läuft, verliert im Ernstfall Tage.
Zu einer professionellen IT-Betreuung gehört deshalb eine verlässliche Übersicht über alle Laufzeitumgebungen, ein fester Ablauf für Updates und Neustarts und ein Monitoring, das ungewöhnliches Verhalten eines Dienstes früh meldet.
Häufige Fragen
Häufige Fragen
Was ist Node2Shell?
Node2Shell ist die Bezeichnung für die Sicherheitslücke CVE-2026-111497 in Node.js. Sie steckt im Programmteil, der Brotli-komprimierte Daten entpackt, und kann im ungünstigsten Fall das Ausführen von fremdem Programmcode auf dem Server ermöglichen. Behoben ist sie in Node.js 22.23.4, 24.22.1 und 26.12.1. Netzware unterstützt Unternehmen in Wien und Österreich dabei, betroffene Systeme zu finden und abzusichern.
Woran erkenne ich, ob wir Node.js einsetzen?
Von außen ist das kaum zu erkennen. Am verlässlichsten fragen Sie die Agentur oder den Softwarepartner, der Ihre Webanwendungen entwickelt hat, und den Betreiber Ihrer Server. Wenn die Übersicht fehlt, schafft eine IT-Bestandsaufnahme Klarheit über alle eingesetzten Systeme.
Unsere Agentur hat die Anwendung gerade aktualisiert. Reicht das?
Nicht unbedingt. Ein Update der Anwendung und ihrer Bausteine schließt die aktuellen Lücken nicht, weil sie in Node.js selbst liegen. Lassen Sie sich die laufende Node.js-Version bestätigen. Netzware prüft das gerne gemeinsam mit Ihrer Agentur.
Müssen die Anwendungen für das Update neu gestartet werden?
Ja. Eine laufende Anwendung verwendet die alte Version weiter, bis sie neu gestartet wird. Bei Containern muss zusätzlich das Image neu gebaut werden. Der Neustart dauert meist nur kurz, sollte aber geplant werden, damit Kunden und Mitarbeiter nicht mitten in der Arbeit unterbrochen werden.
Was passiert mit Anwendungen auf Node.js 20 oder älter?
Für diese Versionen gibt es keine offiziellen Sicherheitsupdates mehr. Sie sollten rasch auf eine unterstützte Version umgestellt werden; vorher muss geprüft werden, ob die Anwendung mit der neuen Version funktioniert. Netzware plant solche Umstellungen gemeinsam mit Ihnen und Ihrem Softwarepartner.
IT-Sicherheit
Laufen Ihre Webanwendungen auf einer gepatchten Version?
Wir prüfen gemeinsam mit Ihnen, wo Node.js im Einsatz ist und ob die Updates tatsächlich aktiv sind.