11. November: Node.js-Sicherheitsupdates für unterstützte und nicht mehr unterstützte Versionen

Wichtigste Erkenntnisse

• Node.js plant am 11. November oder kurz danach die Veröffentlichung von Korrekturen mit hohem Schweregrad für die Versionen 22.x, 24.x und 26.x.
• Upstream behandelt Versionen, deren Lebensdauer abgelaufen ist, als betroffen, stellt jedoch keine Korrekturen dafür bereit.
• ELS for Runtimes bereitet Backport-Korrekturen für acht Node.js-Versionen vor, deren Support ausgelaufen ist, und zwar für alle unterstützten Distributionen.
• Starten Sie nach der Aktualisierung jede Node.js-Anwendung neu und überprüfen Sie die Backports für auslaufende Pakete anhand der jeweiligen Paketversion, nicht node --version.

Node.js hat die nächste Runde von Sicherheitsupdates für Mittwoch, den 11. November 2026, oder kurz danach angesetzt. Es werden neue Versionen für die Versionsreihen 22.x, 24.x und 26.x erscheinen, und das Projekt stuft das schwerwiegendste Problem in jeder Versionsreihe als „High“ ein. CVE-IDs und technische Details werden bis zur Veröffentlichung der Updates unter Verschluss gehalten, sodass frühzeitige Behauptungen über bestimmte Angriffsmethoden mit einer gesunden Portion Skepsis betrachtet werden sollten.

Für Teams, die Node.js über alt-nodejs Pakete – die Ankündigung ist nur die halbe Wahrheit. Dazu gehören CloudLinux-Hosting-Server sowie die Debian-, Ubuntu-, Alpine- und Enterprise-Linux-Hosts, die vom „Endless Lifecycle Support“ (ELS) von TuxCare für Node.js abgedeckt werden. Ein auf nodejs.org veröffentlichter Fix patcht für sich genommen noch nichts, was auf diesen Systemen läuft. Aktualisierte Pakete müssen erstellt, veröffentlicht und installiert werden, und laufende Anwendungen müssen neu gestartet werden, bevor der Fix wirksam wird. Der Großteil der Vorbereitungsarbeiten kann bereits jetzt erfolgen, lange bevor weitere Details bekannt gegeben werden.

Die Endleitungen stromaufwärts lassen sich nicht reparieren

Die Upstream-Veröffentlichung umfasst ausschließlich die Versionen 22, 24 und 26. In der Node.js-Sicherheitsmitteilung heißt es, dass Versionen, deren Lebenszyklus abgelaufen ist, bei jeder Sicherheitsveröffentlichung betroffen sind, auch wenn Upstream keine Korrekturen mehr dafür bereitstellt. Das bedeutet zwar nicht, dass jede alte Version jeden neu behobenen Fehler enthält, aber keine Anwendung, die mit Node.js 20, 18 oder einer älteren Version läuft, sollte als sicher angesehen werden, nur weil ihre Version nicht auf der Veröffentlichungsliste steht.

Genau diese Lücke schließt „ELS for Runtimes“. Das ELS-Team von TuxCare bereitet derzeit zurückportierte Korrekturen für acht Produkte vor, deren Lebenszyklus beendet ist alt-nodejs Zeilen, Node.js 10, 12, 14, 16, 18, 19, 20 und 23, sodass eine Anwendung, die an eine ältere Laufzeitumgebung gebunden ist, die Korrekturen dieser Runde als Paketaktualisierung statt als Notfallmigration übernehmen kann. Backporting ist echte Entwicklungsarbeit – der Fix muss an Code angepasst werden, der vom Upstream nicht mehr gepflegt wird –, aber es ist geplant, diese Builds am 11. November zusammen mit allem anderen kurz nach der Upstream-Veröffentlichung bereitzustellen. Die ELS für Runtimes – Dokumentation listet auf, welche Node.js-Versionen auf den jeweiligen Betriebssystemen unterstützt werden.

In welchen Repositories sind die korrigierten Builds enthalten?

Auf CloudLinux läuft der Node.js Selector auf alt-nodejs Pakete, und die Node.js-Version wird pro Anwendung ausgewählt, nicht pro Server oder gar pro Konto. Auf diese Weise kommt es vor, dass auf einem Hosting-Server still und leise drei oder vier Node.js-Versionen nebeneinander laufen, darunter auch einige, die vom Hersteller nicht mehr unterstützt werden.

Das Gleiche alt-nodejs Die Pakete werden für ELS-Kunden ebenfalls über die Repositorys von TuxCare bereitgestellt und decken Debian 10 bis 13, Ubuntu 18.04 bis 26.04 sowie Alpine 3.23 und 3.24 ab, zusätzlich zu den von TuxCare signierten Builds für Enterprise Linux. Sie lassen sich unter /opt/alt/, zusätzlich zu der Node.js-Version, die bereits in der Distribution enthalten ist, und aktualisieren Sie wie gewohnt yum, apt, oder apk Workflow. Node.js 23-Builds werden nur für Debian 12, Debian 13 und Alpine angeboten.

Wann werden die aktualisierten Pakete verfügbar sein?

CloudLinux plant, mit der Entwicklung zu beginnen, sobald Node.js die Korrekturen veröffentlicht, und rechnet damit, eine aktualisierte Version herauszugeben alt-nodejs Pakete noch am selben Tag. Das umfasst die Versionen 22, 24 und 26 sowie die auslaufenden Versionen aller CloudLinux-Versionen von 6 bis 10, und die Builds aus dem TuxCare-Repository werden im selben Durchlauf bereitgestellt. Dieser Zeitplan hängt von der Veröffentlichung des Upstream-Projekts ab, es handelt sich also eher um ein Ziel als um einen festen Liefertermin.

CloudLinux-Hosts verfügen über zwei weitere Node.js-Pakettypen mit eigenen Aktualisierungspfaden. Auf cPanel-Servern, auf denen CloudLinux 8 läuft, ea-nodejs22 stammt ebenfalls aus den CloudLinux-Repositories, wird jedoch aus dem cPanel-Paket kompiliert. Die Behebung des Problems hängt davon ab, dass cPanel zunächst eine aktualisierte Version veröffentlicht und CloudLinux anschließend das entsprechende Paket zur Verfügung stellt. Die native Funktion des Betriebssystems nodejs Pakete werden wieder über einen separaten Weg bereitgestellt, nämlich über die regulären RHEL- und AlmaLinux-basierten Betriebssystem-Updates. Jede außerhalb dieser Kanäle installierte Laufzeitumgebung muss separat überprüft werden, da eine alt-nodejs Das Update wird das nicht berühren.

Vorbereitungsarbeiten, die es sich lohnt, noch vor Mittwoch zu erledigen

Auf CloudLinux sollten Sie die CloudLinux-Statusseite für diese Version abonnieren. CloudLinux plant, am Dienstag, dem 10. November, frühzeitig eine voraussichtliche Veröffentlichungszeit bekannt zu geben und anschließend alle paar Stunden Fortschrittsberichte zu veröffentlichen, bis die Pakete verfügbar sind. ELS-Kunden, die andere Distributionen nutzen, können in der Liste der verfügbaren Node.js-Korrekturen von TuxCare nach korrigierten Builds Ausschau halten.

Führen Sie als Nächstes eine Bestandsaufnahme durch. Führen Sie den Befehl aus, der zum Paketmanager des Hosts passt (RPM, DEB oder APK):

rpm -qa 'alt-nodejs*'
dpkg -l 'alt-nodejs*'
apk info | grep alt-nodejs

Dadurch wird angezeigt, welche Versionen installiert sind, nicht jedoch, welche Anwendungen diese nutzen. Überprüfen Sie unter CloudLinux auch den „Node.js Selector“, um zu sehen, welche Version den einzelnen Anwendungen zugewiesen ist. An anderer Stelle können systemd-Einheiten, PM2-Konfigurationen und Container-Images jeweils auf unterschiedliche Binärdateien verweisen; überprüfen Sie daher auch diese. Eine Anwendung, die während des Aktualisierungsfensters übersehen wurde, kann weiterhin mit einer alten Laufzeitumgebung laufen, während alles andere auf dem neuesten Stand zu sein scheint.

Planen Sie daher einen Neustart ein, da die Aktualisierung des Pakets allein nicht ausreicht. Durch die Installation eines aktualisierten Pakets wird zwar die Binärdatei auf der Festplatte ersetzt, eine laufende Node.js-Anwendung verwendet jedoch weiterhin die alte Version, bis sie neu gestartet wird – unabhängig davon, was der Paketmanager anzeigt.

Anwendungen, die über den Node.js Selector verwaltet werden, können über dessen Benutzeroberfläche oder mit diesem Befehl neu gestartet werden, wobei der Kontoname und das Anwendungsverzeichnis anzugeben sind:

cloudlinux-selector restart --json --interpreter nodejs --user <user> --app-root <app_root>

Alles, was außerhalb von Node.js Selector läuft, wird gemäß der üblichen Verwaltung dieses Dienstes neu gestartet. Anschließend werden hier alle laufenden Node.js-Prozesse mit ihrer Startzeit aufgelistet, sodass alles, was vor dem Update gestartet wurde, besonders auffällt:

ps -eo pid,lstart,args | grep -E '[n]ode( |$)'

Auf Servern, auf denen viele Anwendungen gehostet werden, sollten Sie die Reihenfolge der Neustarts im Voraus festlegen und sich mit den Anwendungsverantwortlichen abstimmen, wenn Ausfallzeiten eine Rolle spielen. Ein geplanter, gestaffelter Neustart ist besser als ein überstürzter Neustart in der Nacht der Veröffentlichung.

Was ist zu tun, sobald die Pakete angekommen sind?

Wenn die betreffende alt-nodejs Die Pakete sind verfügbar. Installieren Sie sie über Ihr übliches Paketverwaltungssystem und starten Sie die betroffenen Anwendungen neu. Vergewissern Sie sich anschließend, dass jede Anwendung einwandfrei wieder gestartet wurde und mit der aktualisierten Laufzeitumgebung läuft. Eine erfolgreiche Paketinstallation ist kein Beweis dafür, dass jede Anwendung die Korrektur übernommen hat.

Zeilen am Ende der Lebensdauer erfordern eine zusätzliche Überprüfung. Die Pakete 22, 24 und 26 werden in die neuen Upstream-Versionen übernommen, sodass sich ihre Versionsnummer wie erwartet ändert. Ein Backport funktioniert anders: Dabei wird der Fix auf die bestehende Version aufgesetzt, sodass die Upstream-Version von Node.js gleich bleibt und sich nur die Versionsnummer des Pakets ändert. Bei diesen Zeilen node --version Da es vor und nach dem Update identisch aussieht, sollten Sie stattdessen die installierte Paketversion mit der korrigierten Version vergleichen, die CloudLinux oder TuxCare veröffentlichen. Scanner, die lediglich Versionszeichenfolgen vergleichen, können auf dasselbe Problem stoßen und einen gepatchten Backport als anfällig kennzeichnen.

Der Node.js-Sicherheitshinweis wird die Details zur Sicherheitslücke sowie die korrigierten Upstream-Versionen enthalten, sobald die Releases veröffentlicht sind. Auf einer alt-nodejs Auf dem Host ist die praktische Frage jedoch einfacher. Wurde das aktualisierte Paket installiert und wurde die App darauf neu gestartet? Was die Zeilen betrifft, die Upstream zurückgelassen hat, ELS für Laufzeiten sorgt dafür, dass regelmäßig Korrekturen bereitgestellt werden, sodass Migrationen nach einem vom Team festgelegten Zeitplan erfolgen können, anstatt nach einem Zeitplan, den eine Beratungsstelle für das Team festlegt.

ELS für Laufzeiten herunterladen →

Referenzen

Node.js, „Sicherheitsupdates vom Mittwoch, 11. November 2026“

CloudLinux-Statusseite: „Sicherheitsupdates für Node.js, 11. November 2026“

TuxCare Dokumentation