Technischer Support
Dokumentation
Anmeldung
Kontakt
Gehen Sie direkt zu einer KI-Zusammenfassung dieses Blogbeitrags 
Wichtigste Erkenntnisse
- Node.js 20 hat am 30. April 2026 das Ende seines Lebenszyklus erreicht und erhält nun ebenso wie Node.js 18 und alle früheren Versionen keine Sicherheitspatches mehr vom Projekt.
- Eine EOL-Version von Node.js bedeutet, dass bereits öffentlich bekannte CVEs nicht mehr gepatcht werden und dass für später entdeckte Sicherheitslücken keine Korrekturen mehr bereitgestellt werden.
- Jede offizielle Node.js-Binärdatei enthält etwa 25 Komponenten. Einige davon, wie OpenSSL, zlib und ICU, sind auch als Systembibliotheken vorhanden, die Ihr Betriebssystem an anderer Stelle aktualisiert, jedoch niemals innerhalb von Node.js; andere, wie V8 und undici, verfügen über keinerlei Systempaket, sodass Korrekturen aus dem Upstream nur über einen neuen Node.js-Build zu Ihnen gelangen. Jede mitgelieferte Kopie wird zum Ende der Lebensdauer (EOL) eingefroren.
- Sie haben folgende Möglichkeiten: ein Upgrade auf eine unterstützte LTS-Version, die Abwanderung von Node.js oder die Inanspruchnahme des erweiterten Supports, um weiterhin Patches zu erhalten, während Sie die Umstellung nach Ihrem eigenen Zeitplan planen.
Falls in einem Teil Ihres Stacks noch Node.js 18 oder 20 läuft, sind Sie damit in guter Gesellschaft. LTS-Versionen mit geraden Nummern werden in der Produktion weit verbreitet eingesetzt und funktionieren auch nach Ablauf des Supports weiterhin. Es werden lediglich keine Fehlerbehebungen mehr bereitgestellt. Node.js 20 hat diese Grenze am 30. April 2026 überschritten, und alle vorherigen Versionen hatten sie bereits zuvor überschritten.
In diesem Beitrag wird erläutert, welche Node.js-Versionen das Ende ihrer Lebensdauer erreicht haben, was dies für die Sicherheit und Compliance der darauf basierenden Anwendungen bedeutet und welche drei realistischen Vorgehensweisen es gibt: Upgrade, Migration oder die Nutzung des erweiterten Supports für Node.js, um weiterhin Patches zu erhalten, während Sie eine Entscheidung treffen.
Welche Node.js-Versionen sind nicht mehr unterstützt?
Seit Juli 2026 erhalten nur noch drei Versionszweige Updates vom Node.js-Projekt: 26.x (aktuell), 24.x (aktiver LTS) und 22.x (Wartungs-LTS). Node.js 20 und alle früheren Versionen sind nicht mehr unterstützt, ebenso wie die ungeraden Versionszweige, die nie in den LTS-Status übergegangen sind.
| Version (Codename) | Status | Der Support endet |
| 26.x | Aktuell; wird im Oktober 2026 in den LTS-Status übergehen | April 30, 2029 |
| 24.x (Krypton) | Aktives LTS | April 30, 2028 |
| 22.x (Jod) | Wartung LTS | April 30, 2027 |
| 25.x, 23.x, 21.x, 19.x | Ende der Lebensdauer; wurde nie in die LTS-Version aufgenommen | Juni 2026 und früher |
| 20.x (Eisen) | Ende des Lebens | April 30, 2026 |
| 18.x (Wasserstoff) | Ende des Lebens | April 30, 2025 |
| 17.x und früher | Ende des Lebens | 2023 oder früher |
Node.js hat in der Vergangenheit zwei Hauptversionen pro Jahr veröffentlicht, wobei die Versionen mit geraden Nummern in den Long-Term-Support (LTS) übernommen wurden: etwa sechs Monate als „Current“, zwölf Monate als „Active LTS“ mit Fehlerbehebungen und Sicherheitsupdates, gefolgt von einer Wartungsphase, in der nur noch kritische Fehler behoben werden – insgesamt etwa 30 Monate LTS oder rund 36 Monate vom ersten Release bis zum Ende des Lebenszyklus.
Dieses Modell ändert sich. Ab Node.js 27 wechselt das Projekt zu ein Hauptrelease pro Jahr, jede Version wird zur LTS-Version, und die Versionsnummern richten sich nach dem Kalenderjahr: 27.0.0 im Jahr 2027, 28.0.0 im Jahr 2028. Im Oktober 2026 wird ein neuer Alpha-Kanal eröffnet, der die Rolle der frühen Testphase übernimmt, die bisher die ungeraden Versionsreihen innehatten, und Node.js 26 ist die letzte Version nach dem alten Modell. Die Gesamtunterstützungsdauer bleibt unverändert bei etwa 36 Monaten vom ersten „Current“-Release bis zum Ende der Lebensdauer. Ein besser vorhersehbarer Zeitplan, aber das Endziel ist dasselbe: Für jede Version gibt es nach wie vor ein Datum, nach dem keine Patches mehr bereitgestellt werden.
In unserem speziellen Leitfaden können Sie sich außerdem einen Überblick über unsere detaillierte Analyse des Zeitplans für das Ende der Unterstützung (EOL) von Node.js 18 und die damit verbundenen Auswirkungen verschaffen.
Was das Ende der Unterstützung für Node.js für Ihre Anwendungen bedeutet
Das Node.js-Projekt äußert sich dazu ungewöhnlich direkt. Auf seiner eigenen Seite zum Ende des Lebenszyklus warnt vor vier Konsequenzen: keine Sicherheitspatches mehr, Probleme mit der Toolchain, eine Verschiebung des Ökosystems, da beliebte Pakete die Unterstützung für alte Laufzeiten einstellen, sowie Compliance-Probleme, da „viele Branchenaudits nicht mehr gepflegte Laufzeiten verbieten“.
Die noch nicht behobenen CVEs, die Sie bereits kennen
Node.js veröffentlicht regelmäßig Sicherheitsupdates, wobei in jedem Update die EOL-Zeilen vollständig übersprungen werden. Stand 30. Juli 2026 sind auf der EOL-Seite des Projekts 27 Sicherheitslücken mit hohem Schweregrad für Node.js 20 und 15 für Node.js 18 aufgeführt, und diese Zahlen steigen weiter an.
Das Muster ist es, was dies gefährlich macht. Die Sicherheitsupdate vom 29. Juli 2026 betraf ausschließlich die Versionsreihen 26.x, 24.x und 22.x. Es wurden elf Probleme behoben, darunter drei mit hohem Schweregrad, darunter ein HTTP/2-Reentrancy-Fehler im mitgelieferten nghttp2, der zu einem „Use-after-free“-Fehler im Heap des Prozesses führt. Node.js 20 und 18 erhielten keine Korrekturen, und der Sicherheitshinweis verriet Angreifern genau, wo sie in jeder Version, die den Fix nicht erhielt, suchen mussten. Öffentlicher Sicherheitshinweis, öffentlicher Patch, öffentlicher Diff. Der Großteil der Aufklärungsarbeit ist bereits erledigt.
Um einen Eindruck davon zu bekommen, wie eine schwerwiegende Schwachstelle aussieht, sehen Sie sich „HTTP/2 Rapid Reset“ an (CVE-2023-44487) als Beispiel. Diese Schwachstelle wurde als Zero-Day-Exploit ausgenutzt, um die damals größten jemals verzeichneten DDoS-Angriffe zu starten, und betraf jeden Node.js-Server, auf dem HTTP/2 aktiviert war. Für Node.js 18 und 20 wurden innerhalb weniger Tage Patches bereitgestellt. Würde dieselbe Schwachstelle heute bekannt werden, würde keine der beiden Versionen jemals einen Patch vom Node.js-Projekt erhalten.
Die CVEs, für die es niemals einen Patch geben wird
Das Node.js-Sicherheitsteam bewertet oder behebt keine Sicherheitslücken in EOL-Versionen. Im Januar 2025 versuchte das Projekt, dies für Schwachstellenscanner sichtbar zu machen, indem es CVE-2025-23087, eine pauschale CVE, die Node.js 17 und alle früheren Versionen abdeckt, sowie begleitende CVEs für die Versionen 19 und 21. Das CVE-Programm lehnte alle drei ab. Die Ersatzrichtlinie ist umfassender: Jede neue Node.js-CVE deckt nun standardmäßig EOL-Release-Linien ab, es sei denn, dem Projekt liegen konkrete Informationen vor, dass dies auf eine bestimmte Version nicht zutrifft.
Node.js 18 und 20 werden also nicht in einer pauschalen EOL-Mitteilung namentlich genannt – es wird davon ausgegangen, dass sie von jeder nachfolgenden Mitteilung betroffen sind. Als Grund gibt das Projekt Ressourcenengpässe an: Bei mehr als zwanzig EOL-Versionen, die jeweils unterschiedliche Abhängigkeiten und Build-Prozesse aufweisen, sowie Sicherheitslücken, die sich je nach Komponenten wie OpenSSL unterschiedlich äußern, ist eine umfassende Bewertung nicht durchführbar. Alle darin gefundenen Probleme bleiben unbewertet und unbehoben.
Warnsignale im Bereich Compliance
Prüfer gelangen auf einem anderen Weg zu demselben Ergebnis. PCI DSS 4.x Anforderung 6.3.3 sieht vor, dass Patches für kritische Schwachstellen, die im Rahmen Ihres eigenen Risikobewertungsprozesses identifiziert wurden, innerhalb eines Monats nach ihrer Veröffentlichung installiert werden müssen – eine Anforderung, die kein Prozess erfüllen kann, wenn kein Patch verfügbar ist. Die Sicherheitskriterien von SOC 2 setzen einen funktionierenden Schwachstellenmanagementprozessvoraus, und Software ohne Patch-Quelle macht es schwierig, dies nachzuweisen. Bei Workloads auf Bundesebene und in regulierten Bereichen kann eine nicht gewartete Laufzeitumgebung bereits für sich genommen einen Beanstandungspunkt darstellen, noch bevor jemand nach bestimmten CVEs fragt.
Das verborgene Risiko: Der mitgelieferte Abhängigkeitsbaum von Node.js
Das ist der Punkt, der selbst erfahrene Teams überrascht: Node.js ist nicht einfach nur Node.js. Die Abhängigkeitsdokumentation listet 30 Komponenten im Quellcode-Baum auf, von denen etwa 25 in jeder offiziellen Node.js-Binärdatei enthalten sind. Dazu gehören die V8-JavaScript-Engine, die libuv-Ereignisschleife, der llhttp-HTTP-Parser, der undici-HTTP-Client, nghttp2, nghttp3 und ngtcp2 für HTTP/2 und HTTP/3, der c-ares-DNS-Resolver, zlib, brotli und zstd zur Komprimierung, ICU, SQLite, npm selbst sowie die Node-eigene OpenSSL-Implementierung. (Die genaue Zusammensetzung variiert je nach Hauptversion – Node.js 18 und 20 sind beispielsweise älter als die mitgelieferten Versionen von SQLite und zstd.)
Diese Komponenten lassen sich in zwei Gruppen einteilen, und beide stellen nach Ablauf der Lebensdauer (EOL) ein Problem dar. Etwa die Hälfte davon existiert auch als Systembibliothek: OpenSSL, zlib, SQLite, ICU, nghttp2, c-ares, libuv. Ihr Betriebssystem patcht diese an anderer Stelle im System, aber offizielle Node.js-Binärdateien – jene von nodejs.org, von Versionsmanagern wie nvm und die Standard-Docker-Images – werden mit ihren eigenen Kopien kompiliert, und Betriebssystem-Updates erreichen sie nie. (Einige Pakete von Linux-Distributionen verweisen stattdessen auf einige Systembibliotheken, aber das ist die Ausnahme.) Die andere Hälfte, darunter V8, llhttp, undici und npm, wird im Upstream gepflegt, verfügt jedoch nirgendwo auf Ihrem Rechner über ein Systempaket. Daher erreicht Sie eine Korrektur im Upstream-Projekt erst dann, wenn ein neuer Node.js-Build diese enthält. In beiden Fällen ist die Schlussfolgerung dieselbe: Korrekturen erreichen Sie entweder über einen neuen Node.js-Build oder gar nicht, und wenn eine Release-Linie das Ende ihrer Lebensdauer (EOL) erreicht, friert der gesamte Code-Baum ein.
Hier geht es nicht um eine theoretische Sicherheitslücke. „Rapid Reset“ war eine Schwachstelle auf HTTP/2-Protokollebene, die Node.js über das mitgelieferte nghttp2 behoben hat – nicht im Code, den das Node.js-Team geschrieben hat. Das Sicherheitsupdate vom Juli 2026 enthielt neben den eigenen Korrekturen von Node auch Updates für undici und llhttp. Auf einer unterstützten Version werden diese automatisch bereitgestellt. Bei einer EOL-Version sammelt jede dieser Komponenten stillschweigend alle für sie geltenden Upstream-CVEs an, ohne dass ein Weg für die Bereitstellung der Korrekturen besteht.
Jede seriöse Option für erweiterten Support muss diesen gesamten Bereich abdecken. Aus diesem Grund patcht der „Endless Lifecycle Support“ (ELS) von TuxCare den gesamten mitgelieferten Abhängigkeitsbaum und nicht nur den Node.js-Kern.
Ihre Optionen nach dem Ende der Unterstützung für Node.js
Drei konkrete Wege – und welcher der richtige ist, hängt davon ab, wie viel Migrationsrisiko Sie derzeit verkraften können:
- Sie können in diesem Quartal kein Upgrade durchführen, müssen aber auf dem neuesten Stand bleiben? Erweiterter Support.
- Verfügen Sie über die erforderlichen Entwicklungsressourcen und eine kompatible Abhängigkeitskette? Führen Sie ein Upgrade auf eine unterstützte LTS-Version durch.
- Ist Node.js nur ein kleiner oder immer kleiner werdender Teil Ihres Stacks? Dann sollten Sie in Betracht ziehen, Node.js gleich ganz abzuschaffen, wenn Sie schon dabei sind.
Nutzen Sie den unbefristeten Lebenszyklus-Support für Node.js
Der schnellste Weg, das unmittelbare Risiko zu beseitigen, ohne Ihren Code zu verändern, sind vom Anbieter bereitgestellte Patches. TuxCares ELS für Node.js bietet fortlaufende Sicherheitskorrekturen für Node.js 12, 14, 16, 18 und 20: Patches werden aus dem Upstream-Projekt zurückportiert, auf Integrität und Regressionen getestet, signiert, durch ein SLA abgesichert und über die von Ihnen bereits verwendeten Paketmanager bereitgestellt. TuxCare bietet dies als Partner im Rahmen des Ecosystem Sustainability Program der OpenJS Foundationan und ist als kommerzieller Support-Anbieter auf der auf der EOL-Seite des Node.js-Projektsaufgeführt.
Der Umfang umfasst den oben beschriebenen gebündelten Abhängigkeitsbaum – von OpenSSL bis hin zu undici – ohne zusätzliche Kosten. Aktuelle Sicherheitslücken und Korrekturen für Node.js können Sie im TuxCare CVE Tracker einsehen, um genau zu erfahren, was gepatcht wird.
Um die Rolle, die dies spielt, klar zu machen: Es handelt sich um eine Brücke, nicht um ein Ziel. ELS gleicht aus, was EOL wegnimmt: Zeit, um ein Upgrade nach Ihren eigenen Vorstellungen zu planen, anstatt unter dem Druck von Vertragsverletzungen oder Audits.
Auf eine unterstützte LTS-Version aktualisieren
Die saubere, langfristige Lösung. Node.js 24 vereint jahrelange Arbeit an der Leistungsoptimierung, aktuelle V8-Funktionen und Support bis zum 30. April 2028. Node.js 22 wird ebenfalls weiterhin unterstützt, allerdings nur bis zum 30. April 2027, was es eher zu einer Zwischenstation als zu einem Endziel macht. Wenn Ihr Abhängigkeitsbaum in Ordnung ist und Ihre Testabdeckung angemessen ist, ist ein Sprung um eine Hauptversion oft gut zu bewältigen.
Der Aufwand steigt jedoch mit der Dauer und der Komplexität des Quellcodes. Jede Hauptversion bringt kompatibilitätsbrechende Änderungen mit sich, native Add-ons müssen für die neue ABI neu kompiliert werden, und für Pakete, die vor Jahren festgepinnt wurden, gibt es möglicherweise keine kompatible Version mehr. Der Sprung von 18 auf 24 ist nicht nur eine Migration, sondern drei aufeinanderfolgende.
Auf eine andere Technologie umsteigen
Wenn ein Dienst ohnehin neu geschrieben werden muss, kann das EOL der Auslöser dafür sein, auf das umzusteigen, was Ihr Unternehmen derzeit als strategisch wichtig erachtet – sei es eine andere Laufzeitumgebung wie Deno oder Bun oder eine völlig andere Programmiersprache. Diese Flexibilität ist real, aber ebenso real sind die Kosten: Eine Migration kann bedeuten, dass ein Großteil der Funktionen des Dienstes neu geschrieben werden muss, was mit einem erheblichen Testaufwand verbunden ist. Als Reaktion allein auf das EOL ist dies selten sinnvoll.
Die Risiken einer überstürzten Aktualisierung
Ein Upgrade auf eine neue Hauptversion von Node.js ist ein Projekt und keine einfache Aktualisierung einer Abhängigkeit. Das bedeutet, den Code an API-Änderungen anzupassen, die Kompatibilität in der gesamten Lock-Datei zu überprüfen, native Module neu zu kompilieren, CI-Images, Dockerfiles und Build-Toolchains zu aktualisieren sowie Regressionstests für alle Komponenten durchzuführen, die mit der Laufzeitumgebung in Berührung kommen.
Teams, die diese Arbeit in einer Notsituation zusammenpressen – meist, weil ein Audit oder eine veröffentlichte CVE sie dazu zwingt –, zahlen dafür in der Regel später den Preis: Instabilität in der Produktion aufgrund unzureichend getesteter Pfade, ein sprunghafter Anstieg des Supportaufwands, provisorische Lösungen, die sich zu technischer Schuld verfestigen, und ungeplante Kosten genau dort, wo das Budget sie nicht vorgesehen hatte. Dieses Muster tritt so zuverlässig auf, dass die Vermeidung eines erzwungenen Upgrade-Szenarios an sich schon eine Sicherheitsstrategie darstellt. Termindruck und sorgfältige Entwicklung vertragen sich nicht.
Sicherheit für Node.js auch nach Ablauf der Supportfrist mit TuxCare
TuxCare hat über ein Jahrzehnt damit verbracht, die Grundlagen für das Patchen von Sicherheitslücken auf Unternehmensniveau zu entwickeln, und stellt heute zurückportierte Korrekturen für mehr als 2.300 Unternehmenskunden aus den Bereichen Finanzdienstleistungen, Telekommunikation, Gesundheitswesen und öffentliche Verwaltung bereit. Der Patching-Prozess verbindet automatisierte Schwachstellenüberwachung, Patch-Bewertung und Backporting mit einer Validierung durch Experten. Jede Version wird aus geprüften Quellen erstellt und signiert, wobei Bescheinigungen die Abhängigkeiten abdecken.
Für Node.js bedeutet dies kontinuierliche Sicherheitspatches, Stabilität und Nachweismöglichkeiten für die Versionen, auf denen Ihre Anwendungen tatsächlich laufen: Abdeckung der gebündelten Abhängigkeiten, Korrekturen, die über Ihre bestehenden Paketmanager bereitgestellt werden, und Kosten, die nur einen Bruchteil der Kosten einer ungeplanten Migration ausmachen. Entdecken Sie ELS für Node.jsoder beginnen Sie mit dem CVE-Tracker , um aktuelle Sicherheitslücken und Korrekturen für Node.js zu überprüfen.
