Node.js-Sicherheitsupdate: erhält Ihre Version noch Sicherheitsupdates?

Ein Sicherheitsupdate haben nur die Release-Zweige erhalten, für die noch Support besteht, und sicher sind die Versionen 22.23.4, 24.22.1 und 26.12.1 oder neuere Versionen im selben Release-Zweig. Node.js 18 und 20 haben das End of Life bereits erreicht, deshalb enthält dieses Node.js-Sicherheitsupdate für sie kein Sicherheitsupdate und wird auch keines enthalten: läuft Ihre Anwendung auf einer von beiden, bedeutet die Aktualisierung den Wechsel auf einen anderen Zweig.

Am Mittwoch, dem 21. Oktober, hat das Node.js-Projekt Sicherheits-Releases für alle drei unterstützten Zweige veröffentlicht, und am selben Tag hat PHP Notfall-Sicherheitsupdates für die Sicherheitslücken veröffentlicht, die den Namen PHP2Shell erhalten haben, doch das sind zwei getrennte Ereignisse von unterschiedlicher Schwere. Der Node.js-Release war im Voraus angekündigt, seine schwersten Sicherheitslücken hat das Projekt als hoch bewertet und nicht als kritisch, und die Meldung nennt weder Umgehungen noch Angriffe in der realen Umgebung. Das erlaubt nicht, die Aktualisierung aufzuschieben, verschiebt aber die Aufmerksamkeit: diesmal liegt das größte Risiko nicht im Release selbst, sondern in den Versionen, die ihn nicht erhalten haben.

Was das Node.js-Sicherheitsupdate im Oktober behoben hat

In der Node.js-Meldung sind zehn Sicherheitslücken aufgeführt: vier hat das Projekt als hoch bewertet, drei als mittel und drei als niedrig, CVSS-Bewertungen hat das Projekt diesmal aber nicht veröffentlicht, deshalb verwendet dieser Artikel dieselbe Bewertung.

Die schwerste von ihnen ist CVE-2026-111497. Das Projekt nennt sie ein Schreiben außerhalb der Begrenzungen (Out-of-bounds Write) im Brotli-Dekodierer, das die Ausführung von Code aus der Ferne (Remote Code Execution, RCE) erlaubt, und bewertet sie als hoch. Brotli ist ein Kompressionsformat, dessen Dekodierer in Node.js eingebaut ist, und in den Release Notes ist das Sicherheitsupdate als Änderung in dieser eingebauten Bibliothek beschrieben. Auf welchem Weg die Sicherheitslücke erreichbar ist, sagt die Meldung nicht, und auch die Beschreibung der Änderung durch die Brotli-Entwickler spricht nur davon, dass ein ungültiger Datenstrom jetzt früher erkannt wird. Deshalb sind hier keine konkreten Funktionen genannt: sicher sagen lässt sich nur, dass ein Fehler im Dekodierer vor allem die Anwendungen betrifft, die Brotli-Daten aus einer Quelle dekomprimieren, der sie nicht vertrauen können.

Drei weitere Sicherheitslücken betreffen die Prüfung von TLS-Zertifikaten, und sie sind nicht ein und derselbe Fall. Die erste, als hoch bewertet, betrifft nur die Zweige 26 und 24: die hostname verification (die Prüfung, ob das TLS-Zertifikat zum Host passt, zu dem die Verbindung aufgebaut wird) lässt sich umgehen, wenn eine IP-Adresse mit Ziffern in voller Breite geschrieben ist, zum Beispiel １２７.０.０.１. Die zweite, ebenfalls hoch, betrifft alle drei Zweige: die Prüfung lässt sich umgehen, wenn sich der Hostname bei nicht strikter Lesart als IP-Adresse lesen lässt. Die dritte ist mittel und betrifft ebenfalls alle drei Zweige: eine nicht standardgemäße IPv4-Schreibweise erlaubt es einem im Zertifikat angegebenen DNS-Namen, eine IP-Adresse zu beglaubigen. In den Release Notes sind die Korrekturen knapp formuliert: ungewöhnlich geschriebene IP-Adressen werden jetzt abgelehnt, und gesondert ist eine Regression bei der Normalisierung von IP-Adressen behoben. In allen drei Fällen geht es um den Moment, in dem Node.js als Client arbeitet, also selbst eine verschlüsselte Verbindung zu einem anderen Server aufbaut, und nicht um den Moment, in dem es seine eigenen Besucher bedient.

Die vierte als hoch bewertete Sicherheitslücke liegt in der Funktion dns.resolve, die Namen abgeschnitten hat, in denen ein Nullzeichen vorkommt. Unter den mittleren ist ein Fehler bei der Wiederverwendung von HTTP-Verbindungen, bei dem eine Antwort, die in die Verbindung geschrieben wurde, bevor die Anfrage gesendet war, als Antwort auf diese Anfrage verarbeitet werden konnte, und ein Fehler, durch den der Zufalls-Cache von crypto.randomUUID() und randomInt() in startup snapshots und in einer single executable application gespeichert wurde, sodass jeder Prozess dieselben Werte wiederholte. Drei als niedrig bewertete Sicherheitslücken betreffen die Verarbeitung von ZIP-Dateien und das Berechtigungsmodell von Node.js.

Den Fehler im Zufalls-Cache genauer zu verstehen lohnt sich, weil er im gewöhnlichen Fall gar nichts beeinflusst. Er betrifft nur Projekte, die von einem selbst erstellten startup snapshot starten oder als single executable application (SEA) verbreitet werden, und dort bedeutet er, dass jeder Prozess, der aus derselben Datei gestartet wurde, dieselben „zufälligen“ Werte erhielt. Wurden in einem solchen Projekt mit crypto.randomUUID() oder randomInt() Kennungen oder temporäre Codes gebildet, konnten sie sich von Prozess zu Prozess wiederholen, deshalb lohnt es sich nach dem Sicherheitsupdate zu prüfen, ob einer dieser Werte dort verwendet wird, wo er sich nicht erraten lassen darf.

Der Release aktualisiert außerdem mehrere eingebaute Abhängigkeiten, je nach Zweig c-ares, OpenSSL, SQLite und Undici, worauf die eingebaute Funktion fetch beruht. Ebenso ist der Zertifikatsspeicher, die mitgelieferte Liste der vertrauenswürdigen Zertifizierungsstellen, wegen eines kompromittierten eMudhra-Zwischenzertifikats aktualisiert worden, und TLS-Verbindungen lehnen jetzt Ketten ab, die blockierte öffentliche Schlüssel enthalten.

Welche Versionen sicher sind

Die behobenen Versionen sind drei, eine für jeden unterstützten Zweig: 22.23.4, 24.22.1 und 26.12.1. Alles, was im eigenen Zweig älter ist, ist betroffen. Nicht alle zehn Sicherheitslücken betreffen jeden Zweig: der 26er-Zweig hat alle zehn, der 24er-Zweig acht und der 22er-Zweig sieben, weil zwei als niedrig bewertete Fehler nur im neuesten Zweig vorkommen und ein TLS-Fehler den 22er-Zweig nicht betrifft.

Die Aktualisierung innerhalb des Zweigs ist der kleinste mögliche Schritt, und gewöhnlich ist sie auch die sicherste Änderung, die sich in der Produktionsumgebung machen lässt. Auch sie kann das Verhalten aber ändern, und diesmal gibt es ein konkretes Beispiel: die Korrektur der TLS-Prüfung lehnt jetzt ungewöhnlich geschriebene IP-Adressen ab. Hat eine Anwendung in Verbindungen zu einem anderen Server einmal eine solche Schreibweise verwendet, kann die Verbindung nach der Aktualisierung scheitern. Das ist eine behobene Sicherheitslücke, kein neuer Fehler, doch das zu wissen lohnt sich vor der Aktualisierung, nicht erst danach.

Der Release-Zweig ist wichtiger als die Versionsnummer

Bis Node.js 26 durchläuft jede Hauptversion einen Zyklus: zuerst ist sie die aktuelle Version (Current), dann erhalten die geradzahligen Versionen den aktiven Long-Term-Support (Langzeitunterstützung, Active LTS), danach wechseln sie in die Phase Maintenance LTS, in der sie nur kritische Fehlerbehebungen und Sicherheitsupdates erhalten, und am Ende endet der Support ganz, während die ungeradzahligen Versionen bis zum 25er-Zweig keinen Long-Term-Support erhalten haben. Ab Node.js 27 ändert sich der Zyklus: laut dem Release-Zeitplan erhält jeder Release-Zweig Long-Term-Support, und während aller 30 Monate dieses Supports bleibt er im Active LTS, ohne Maintenance LTS. Das Projekt schreibt selbst, dass Produktionsanwendungen nur Releases im Active LTS oder im Maintenance LTS verwenden sollen.

Bei den derzeit verwendeten Zweigen liegen die nächsten Phasenwechsel an zwei Daten. Laut dem Node.js-Release-Zeitplan ist der 24er-Zweig am 20. Oktober in Maintenance LTS gewechselt, einen Tag vor dem Sicherheits-Release, und der 26er-Zweig erhält am 28. Oktober Long-Term-Support. Der 22er-Zweig ist seit dem 21. Oktober 2025 in Maintenance LTS und erreicht am 30. April 2027 das End of Life, der 24er-Zweig erreicht es am 30. April 2028.

Die praktische Bedeutung ist einfach: die Frage „haben wir die neueste Version“ sagt für sich genommen nicht viel, nützlich ist dagegen die Frage „in welchem Release-Zweig sind wir, und bis zu welchem Datum erhält er Sicherheitsupdates“. Die erste Frage ändert ihre Antwort jeden Monat, die zweite einmal alle paar Jahre, und genau deshalb ist die zweite leicht zu vergessen.

Node.js 18 und 20: ein Sicherheitsupdate wird es nicht geben

In der Node.js-Meldung steht ein Satz, der diesmal wichtiger ist als alle zehn Sicherheitslücken: Versionen, die das End of Life erreicht haben, sind bei einem Sicherheits-Release immer betroffen, und ein Sicherheitsupdate wird für sie weder jetzt noch später veröffentlicht, weil ein Zweig, der das End of Life erreicht hat, überhaupt keinen Release mehr erhält.

Laut dem Release-Zeitplan hat der 16er-Zweig am 11. September 2023 das End of Life erreicht, der 19er-Zweig am 1. Juni 2023, der 18er-Zweig am 30. April 2025 und der 20er-Zweig am 30. April 2026. Das letzte dieser Daten ist das wichtigste: der 20er-Zweig hat das End of Life vor knapp sechs Monaten erreicht, und ein Projekt, das auf ihm begonnen wurde, kann noch ohne jedes sichtbare Problem laufen. Genau das macht die Lage tückisch, weil nichts daran, wie es läuft, zeigt, dass ihm Sicherheitsupdates nicht mehr zustehen.

Für Unternehmen, die nicht schnell auf einen unterstützten Zweig wechseln können, nennt die Node.js-Meldung eine Möglichkeit: kommerziellen Support für Versionen nach der Phase Maintenance LTS bieten die Partner des OpenJS Ecosystem Sustainability Program. Es ist ein kostenpflichtiger Dienst, und es ist eine Übergangslösung, kein Ersatz für den Wechsel.

Wie Sie prüfen, welches Node.js Ihre Anwendung verwendet

Die Prüfung dauert Minuten, doch es gibt eine Stelle, an der sie sich leicht falsch machen lässt: die Node.js-Version, die das Terminal zeigt, ist nicht immer dieselbe, mit der die Anwendung arbeitet.

Hosting mit cPanel: Die verwendete Version zeigt der Bereich Software → Setup Node.js App, in dem jede Anwendung eine eigene Zeile hat und die Version aus einer Liste gewählt wird. Die Liste enthält nur die Versionen, die der Hosting-Anbieter auf dem Server installiert hat. Der Befehl node -v kann auf einem solchen Hosting eine andere Version zeigen als diese Einstellung, deshalb sehen Sie sich direkt die betreffende Zeile an.

Eigener Server: Der Befehl node -v zeigt die Version, die im Systempfad an erster Stelle steht, ein Prozessmanager, zum Beispiel PM2 oder ein systemd-Dienst, kann das Programm aber mit einer ganz anderen ausführbaren Datei starten. Die verlässlichste Antwort ist die, die der Prozess über sich selbst meldet: der Wert von process.version, zum Beispiel beim Start ins Protokoll geschrieben.

Container: In einer Docker-Umgebung bestimmt das Container-Image die Version, nicht der Hostrechner. Ein Container-Image, das vor dem 21. Oktober gebaut wurde, enthält das Sicherheitsupdate nicht, unabhängig davon, wie oft der Container neu gestartet wurde; das Container-Image ist deshalb mit einem aktualisierten Basis-Image neu zu bauen.

Wenn Sie keinen Zugang haben: Dann geht die Frage an den Hosting-Anbieter oder an den Entwickler, der die Anwendung pflegt. Eine Formulierung, die den Schriftwechsel spart: „Welche Node.js-Version verwendet unsere Anwendung? Liegt sie in ihrem Zweig mindestens bei 22.23.4, 24.22.1 oder 26.12.1? Liegt sie in einem Zweig, der das End of Life erreicht hat, zum Beispiel 18 oder 20, wann ist der Wechsel geplant?“

Was Sie heute tun

Die Reihenfolge für heute ist diese: zuerst Node.js auf die behobene Version im eigenen Zweig aktualisieren und jeden Prozess neu starten, der es verwendet, dann alles neu bauen, worin die Laufzeitumgebung eingebaut ist, und erst danach den Wechsel für diejenigen Projekte planen, die auf Zweigen laufen, die das End of Life erreicht haben.

Erstens, aktualisieren Sie innerhalb des Release-Zweigs, auf 22.23.4, 24.22.1 oder 26.12.1, je nachdem, in welchem Zweig Sie sind. Beim Hosting tut das der Anbieter, und Ihre Aufgabe ist es, sich zu vergewissern, dass die Anwendung die aktualisierte Version verwendet.

Zweitens, starten Sie die Prozesse neu: Ein Prozess, der bereits läuft, verwendet weiter das Node.js, mit dem er gestartet wurde, und der Austausch der Datei auf der Festplatte berührt ihn nicht. Dasselbe galt auch für PHP2Shell: das Paket ist ausgetauscht, der alte Prozess arbeitet aber mit dem alten Code weiter.

Drittens, bauen Sie neu, wo die Laufzeitumgebung eingebaut ist: Docker-Container-Images sind mit einem aktualisierten Basis-Image neu zu bauen. Wenn Sie das Programm als single executable application (SEA) verbreiten, ist Node.js selbst in dieser Datei eingebaut, sodass die Aktualisierung der auf dem System installierten Version sie nicht berührt, und die Datei ist mit der behobenen Version neu zu bauen. Dasselbe gilt für startup snapshots, die der Fehler im Zufalls-Cache betrifft.

Viertens, wenn Sie auf dem 18er- oder 20er-Zweig sind, planen Sie den Wechsel: Das ist eine größere Arbeit als die Aktualisierung innerhalb des Zweigs; jetzt damit zu beginnen lohnt sich, und die Reihenfolge steht im nächsten Abschnitt.

Wie Sie von Node.js 18 oder 20 wechseln

Ein Wechsel zwischen Hauptversionen ist nicht die Arbeit eines einzigen Befehls, und ihn der Reihe nach zu tun lohnt sich. Zuerst ist das Ziel zu wählen. In den meisten Fällen ist das der 24er-Zweig, der Sicherheitsupdates bis zum 30. April 2028 erhalten wird; der 22er-Zweig ist nur dann eine vernünftige Wahl, wenn eine wichtige Abhängigkeit den 24er-Zweig noch nicht unterstützt, weil sein End of Life ein Jahr früher liegt.

Dann sind alle Stellen zu finden, an denen das Projekt seine Node.js-Version festlegt, denn fast immer sind es mehrere: das Feld engines in package.json, die Dateien .nvmrc oder .node-version, das Basis-Image im Dockerfile, die Konfiguration der kontinuierlichen Integration (CI) und die Einstellung im Hosting-Panel. Wird nur ein Teil davon geändert, laufen in den verschiedenen Umgebungen verschiedene Versionen, und die Fehler zeigen sich dort, wo sie am schwersten zu finden sind.

Danach ist das Projekt in einer Testumgebung mit der neuen Version neu zu installieren, und die Tests sind auszuführen. Besondere Aufmerksamkeit gebührt Paketen mit kompiliertem Code: sie werden für eine bestimmte Node.js-Version gebaut, deshalb kann es sein, dass sie nach dem Wechsel neu gebaut oder aktualisiert werden müssen. Für jede Hauptversion veröffentlicht Node.js eine Liste der Änderungen, in der diejenigen gesondert markiert sind, die vorhandenen Code ungültig machen können, und die zu lesen lohnt sich vor dem Wechsel, nicht erst danach.

Erst dann kommt die Produktionsumgebung: der Versionswechsel, der Neustart der Prozesse und die Prüfung, dass process.version die neue Version zeigt. Die alte Version kann ein paar Tage verfügbar bleiben, für den Fall eines Rückwechsels, aber nicht länger, denn genau das ist die Version, für die es kein weiteres Sicherheitsupdate geben wird.

Was nicht zusammen mit Node.js aktualisiert wird

Die Aktualisierung von Node.js repariert die Laufzeitumgebung selbst und die Bibliotheken, die in ihr eingebaut sind, nicht aber alles, was die Anwendung verwendet, und genau hier bleiben am häufigsten Löcher, die niemand sieht.

Gesondert installierte Pakete: Verwendet das Projekt in seinen Abhängigkeiten das Paket undici von npm und nicht das eingebaute fetch, liegt dieses Paket im Verzeichnis node_modules des Projekts, und ein Node.js-Release berührt es nicht. Dasselbe gilt für alle übrigen Abhängigkeiten: sie aktualisiert der Paketmanager, und nur dann, wenn jemand ihn ausführt.

Zertifikatsspeicher der vertrauenswürdigen Zertifizierungsstellen: Standardmäßig verwendet Node.js nicht die Liste der Zertifizierungsstellen des Betriebssystems, sondern seine eigene eingebaute, und in der Dokumentation heißt es, dass dies eine Momentaufnahme der Mozilla-Liste ist, die zum Zeitpunkt des Release festgehalten wird. Eine Änderung wie die Reaktion dieses Release auf das kompromittierte eMudhra-Zwischenzertifikat erreicht das Programm also nur zusammen mit der Aktualisierung der Laufzeitumgebung und nicht zusammen mit den Aktualisierungen des Betriebssystems, es sei denn, es ist eigens so konfiguriert, dass es die Systemliste verwendet.

Wie Sie den nächsten Release nicht verpassen

Node.js kündigt Sicherheits-Releases im Voraus auf seiner Sicherheitsseite an und nennt dabei den geplanten Tag des Release, und diesmal ist es genau so geschehen. Dieser Mittwoch war also keine Überraschung für diejenigen, die diese Seite beobachten: die Aktualisierung ließ sich schon vorher einplanen, statt am selben Tag noch eine Zeit dafür zu suchen.

In der Praxis heißt das, dass jemand für diese Beobachtung verantwortlich sein muss. Im Managed Hosting tut das der Anbieter; auf Ihrem eigenen Server oder bei einem Projekt, das Ihr eigenes Team pflegt, lohnt es sich aber zu wissen, wer genau die Meldungen des Projekts verfolgt, wer über die Aktualisierung entscheidet und wer prüft, dass danach alles funktioniert. Lautet die Antwort auf diese Fragen „niemand konkret“, liegt genau dort das größte Risiko, und nicht in einer der zehn Sicherheitslücken.

Wenn Node.js für Sie nur ein Build-Tool ist

Auf vielen Laravel- und WordPress-Websites läuft Node.js auf dem Server überhaupt nicht: es betreibt Vite oder ein ähnliches Build-Tool, das aus dem Quelltext die CSS- und JavaScript-Dateien vorbereitet und danach anhält. In diesem Fall unterscheidet sich die Lage von einer Anwendung, die Anfragen selbst bedient, weil der Build-Prozess nicht auf Anfragen aus dem Internet antwortet und keine Daten dekomprimiert, die ihm unbekannte Besucher schicken.

Dass die Lage sich unterscheidet, heißt nicht, dass sie unwichtig ist. Build-Tools arbeiten auf den Rechnern der Entwickler und in der CI-Umgebung, laden Pakete herunter und bauen Verbindungen zu anderen Servern auf, und die Beschreibungen der Sicherheitslücken sind zu kurz, um sicher zu sagen, welche dieser Wege betroffen sind. Node.js auch dort zu aktualisieren lohnt sich, nur in der richtigen Reihenfolge: zuerst die Server, auf denen Node.js live läuft, danach die Rechner der Entwickler und die CI-Umgebung.

Es gibt auch einen zweiten Grund, und er hat mit dieser Woche nichts zu tun. Die Build-Umgebung bleibt oft auf der Node.js-Version, mit der das Projekt einmal begonnen wurde, und dann verweigert eines Tages eine neue Version eines Werkzeugs schlicht die Arbeit mit ihr. Der Wechsel auf einen unterstützten Zweig geschieht dann in Eile und zu einem unpassenden Zeitpunkt; leichter ist er jetzt, solange er noch geplante Arbeit ist.

Was das auf unserem Hosting bedeutet hat

Unser Managed Hosting ist Platz auf unserem eigenen Server, und jeder Kunde wählt dort die Version über das Hosting-Panel. Auf unserem Server laufen die Node.js-Zweige 22 und 24 bereits mit den behobenen Versionen 22.23.4 und 24.22.1. Für Kunden, deren Projekte diese Zweige verwenden, ist nichts zu tun, außer sich zu vergewissern, dass der Prozess nach der Aktualisierung neu gestartet wurde.

Auch die andere Seite ist ehrlich zu sagen. Auf dem Server stehen zur Auswahl weiterhin auch Zweige, die das End of Life erreicht haben, und für sie gibt es kein Sicherheitsupdate – weder auf unserem Server noch auf dem eines anderen, weil Node.js ein solches nicht veröffentlicht. Ist für Ihr Projekt einer davon gewählt, bedeutet die Aktualisierung den Wechsel auf den 22er- oder den 24er-Zweig, und das geschieht am besten zusammen mit der Prüfung, dass nach dem Wechsel alles so funktioniert wie zuvor.

Unser Managed Hosting beginnt ab 45 € im Monat, und gepflegte Laufzeitumgebungen sind ein Teil dessen, wofür man in dieser Summe zahlt. Wenn Ihre Anwendung noch auf Node.js 18 oder 20 läuft, besprechen wir den Wechsel, bevor der Tag eines späteren Sicherheits-Release ihn erzwingt.