Node.js 18: Ende des Supports und Migrationsoptionen

Wichtigste Erkenntnisse

• Node.js 18 hat am 30. April 2025 das Ende seiner Lebensdauer erreicht und erhält keine Sicherheitsupdates oder Fehlerbehebungen mehr vom Node.js-Projekt.
• Das Projekt behandelt jede Release-Reihe, deren Lebenszyklus abgelaufen ist, bei jeder Sicherheitsveröffentlichung als betroffen, sodass die Anzahl der ungepatchten Sicherheitslücken in Node.js 18 nach dem Zeitplan des Projekts und nicht nach Ihrem eigenen zunimmt.
• Node.js 24 ist derzeit die einzige aktive LTS-Version. Node.js 22 befindet sich bereits im Maintenance-LTS-Status und erreicht am 30. April 2027 das Ende seines Lebenszyklus, was es zu einem ungünstigen Migrationsziel macht.
• Der „Endless Lifecycle Support“ von TuxCare sorgt dafür, dass Node.js 18 gegen bekannte Sicherheitslücken gepatcht bleibt, während Teams die Migration in einem realistischen Tempo planen und testen.

Kaum jemand entscheidet sich bewusst dafür, eine End-of-Life-Laufzeitumgebung zu nutzen. Teams geraten in diese Situation, weil das Upgrade-Ticket immer wieder hinter der Arbeit an neuen Releases zurücksteht und weil auf den ersten Blick alles in Ordnung zu sein scheint. Node.js 18 hat am 30. April 2025 – also vor mehr als einem Jahr – das Ende seiner Lebensdauer erreicht und erhält seitdem keine Sicherheitspatches, Fehlerbehebungen oder offiziellen Support mehr vom Node.js-Projekt.

Was viele Teams auf die falsche Fährte führt, ist die Bilanzierung. Das Node.js-Projekt vertritt den Standpunkt, dass Produkte, deren Lebenszyklus abgelaufen ist, bei jeder Veröffentlichung eines Sicherheitsupdates betroffen sind – unabhängig davon, ob sie erneut getestet werden oder nicht. Ihre ungeschützte Fläche vergrößert sich daher jedes Mal, wenn das Projekt eine Sicherheitsempfehlung herausgibt – und zwar in einem Rhythmus, den Sie nicht beeinflussen können.

Dieser Leitfaden behandelt den Zeitplan für das Ende des Supports (EOL) von Node.js 18, welche Version Sie im Jahr 2026 tatsächlich ins Visier nehmen sollten – es ist wahrscheinlich nicht die naheliegende – und wie Sie auf dem neuesten Stand bleiben können, falls die Migration in diesem Quartal nicht abgeschlossen werden kann.

Node.js 18: Ende der Lebensdauer – Was Sie wissen müssen

Es ist hilfreich zu wissen, wie die Node.js Release Working Group den Support konkret strukturiert. Es gibt drei unterstützte Phasen, und „End of Life“ ist der Status, den eine Release-Reihe erreicht, sobald diese Phasen abgeschlossen sind.

Aktuell: Eine neue Hauptversion verbleibt etwa sechs Monate lang in der „Current“-Reihe, was den Autoren von Bibliotheken Zeit gibt, Unterstützung dafür hinzuzufügen. Die Richtlinie des Projekts lautet, dass Produktionsanwendungen ausschließlich Active-LTS- oder Maintenance-LTS-Versionen ausführen sollten.

Aktives LTS: Nach etwa sechs Monaten werden die Versionen mit geraden Nummern für etwa 12 Monate in den Status „Active LTS“ hochgestuft. Diese Phase umfasst mehr als nur Notfallkorrekturen: Sie beinhaltet neue Funktionen, Fehlerbehebungen und Updates, die das Release-Team geprüft und für diese Version als geeignet und stabil befunden hat. Versionen mit ungeraden Nummern werden niemals hochgestuft, weshalb die Versionen 23 und 25 ohne jegliche LTS-Phase vom Status „Current“ direkt in den Status „End of Life“ übergingen.

Wartung: Auf die aktive LTS-Phase folgt eine etwa 18-monatige Wartungsphase, die sich auf die Behebung kritischer Fehler und Sicherheitsupdates beschränkt. Neue Funktionen werden nur selten eingeführt, und zwar in der Regel nur dann, wenn sie Ihnen bei der Migration auf eine neuere Version helfen.

Das ergibt insgesamt etwa 36 Monate von der ersten Veröffentlichung bis zum Ende des Lebenszyklus, davon etwa 30 Monate im Rahmen des LTS-Supports.

Eine Änderung, die Sie bei Ihrer Planung berücksichtigen sollten: Dieses Modell mit geraden und ungeraden Versionen gilt nur bis Node.js 26. Ab Node.js 27 wechselt Node.js zu einem einzigen Hauptrelease pro Jahr, und jedes Hauptrelease wird nach seiner „Current“-Phase zum LTS-Release erhoben. Wenn Sie sich heute für eine Zielversion entscheiden, ist die Phase wichtiger als die Versionsnummer – eine Version, die sich bereits in der „Maintenance“-Phase befindet, wird aus dem Verkehr gezogen, egal wie aktuell sie noch erscheint.

Ende des Supports für Node.js 18: Wichtige Termine

Node.js 18 (Codename „Hydrogen“) wurde am 19. April 2022 veröffentlicht. Am 25. Oktober 2022 trat es in die „Active LTS“-Phase ein, wechselte am 18. Oktober 2023 in die „Maintenance“-Phase und erreichte am 30. April 2025 das Ende seiner Lebensdauer.

 

Wo soll man anfangen: Vergewissern Sie sich vor der Planung, welche Version tatsächlich im Einsatz ist, da in den meisten Umgebungen nicht nur eine Version verwendet wird. Führen Sie auf jedem Host den Befehl „node -v“ aus und überprüfen Sie anschließend Ihre Dockerfiles, CI-Images sowie alle verwalteten Laufzeitkonfigurationen in Lambda, App Runner oder der Plattform Ihrer Wahl.

Risiken von Node.js 18 nach Ablauf der Lebensdauer

Der weitere Betrieb von Node.js 18 nach Ablauf der Lebensdauer führt am ersten Tag zu keinen Störungen – und genau deshalb bleiben die Systeme weiterhin darauf. Alles läuft weiter. Die APIs reagieren weiterhin. Es werden keine Benachrichtigungen ausgegeben.

Was sich geändert hat, ist, dass keine Korrekturen mehr veröffentlicht wurden, während weiterhin Sicherheitslücken entdeckt wurden. Die unten aufgeführten Risiken summieren sich, und jedes einzelne davon lässt sich in einem geplanten Upgrade-Fenster kostengünstiger beheben als während eines Vorfalls. Solange Node.js 18 unterstützt wurde, erhielt es Sicherheitspatches wie jede andere gepflegte Version auch. Diese Veröffentlichungen wurden im April 2025 eingestellt, und das Node.js-Projekt wird keine weiteren Korrekturen dafür herausgeben.

Zunehmende CVE-Exposition

Die offizielle Stellungnahme des Projekts ist ein nützliches Argument, wenn Sie die Arbeit intern rechtfertigen müssen: Versionen, deren Lebenszyklus abgelaufen ist (EOL), sind immer betroffen, wenn ein Sicherheitsupdate veröffentlicht wird. Node.js testet EOL-Versionen nicht erneut, daher werden in den Sicherheitshinweisen nur unterstützte Versionen aufgeführt – doch die anfälligen Codepfade befinden sich nach wie vor in Version 18, und es wird kein offizieller Patch dafür veröffentlicht.

Das Sicherheitsupdate vom 13. Januar 2026 ist ein gutes Beispiel dafür. Es behebt acht Sicherheitslücken in den unterstützten Produktreihen, darunter die folgenden vier:

• CVE-2025-55131 (Hoch) – Eine auf einem Timeout basierende Race Condition führt dazu, dass „Buffer.alloc“ und Typed Arrays nicht mit Nullen gefüllt werden, wodurch nicht initialisierter Speicher offengelegt wird. Erreichbar über das vm-Modul mit Ausführungszeitlimits; dies ist vor allem dort von Bedeutung, wo halbvertrauenswürdiger Code ausgeführt wird.
• CVE-2025-59465 (Hoch) – Ein fehlerhafter HTTP/2-HEADERS-Frame mit ungültigen HPACK-Daten führt durch einen nicht behandelten TLS-Socket-Fehler zum Absturz des Prozesses.
• CVE-2025-59466 (Mittel) – Ein Fehler vom Typ „Maximale Call-Stack-Größe überschritten“ kann nicht mehr abgefangen werden, wenn async_hooks aktiv ist, wodurch process.on(‘uncaughtException’) umgangen wird. Die Auswirkungen sind weitreichender, als es zunächst den Anschein hat: AsyncLocalStorage basiert auf async_hooks, sodass Next.js, React Server Components und die meisten APM-Agenten davon betroffen sind.
• CVE-2026-21637 (Mittel) – Von TLS-PSK- oder ALPN-Callbacks ausgelöste Ausnahmen umgehen die Fehlerbehandlungsroutinen, was zu einem Denial-of-Service und einem File-Descriptor-Leck führt.

Diese Korrekturen wurden in den Versionen 20.20.0, 22.22.0, 24.13.0 und 25.3.0 bereitgestellt. Es gibt kein Äquivalent für die 18.x-Reihe, und es wird auch keines geben.

Hinweis zur Tool-Nutzung: Das Node.js-Projekt pflegt das Paket „is-my-node-vulnerable“, das Ihre installierte Version mit der Node.js-Sicherheitsdatenbank abgleicht. Führen Sie „npx is-my-node-vulnerable“ aus. Beachten Sie jedoch, wie sich das Tool bei einer EOL-Laufzeitumgebung verhält: Anstatt einzelne CVEs aufzulisten, meldet es, dass die Version das Ende ihres Lebenszyklus erreicht hat, und stuft sie standardmäßig als anfällig ein, da EOL-Versionen nicht anhand aktueller Sicherheitsupdates überprüft werden. Für CVE-spezifische Details und den Patch-Status der von TuxCare unterstützten Versionen nutzen Sie den CVE-Tracker.

 

Versäumnisse bei der Einhaltung der Vorschriften

Eine EOL-Laufzeitumgebung scheitert selten allein an einem Audit. Vielmehr nimmt sie die einfachste Möglichkeit weg, die Kontrollmaßnahmen zum Schwachstellenmanagement gemäß PCI DSS, HIPAA, DSGVOsowie ISO 27001, die im Allgemeinen von Ihnen erwarten, dass Sie bekannte Schwachstellen identifizieren und diese innerhalb eines festgelegten Zeitrahmens beheben.

PCI DSS enthält die genauesten Vorgaben hinsichtlich des Zeitrahmens. Anforderung 6.3.3 sieht vor, dass kritische Sicherheitspatches innerhalb eines Monats nach ihrer Veröffentlichung installiert werden müssen. Wenn das Upstream-Projekt keine Patches mehr für Ihre Laufzeitumgebung bereitstellt, können Sie diese Anforderung nicht durch das Installieren von Patches erfüllen, sodass Sie stattdessen Ausgleichsmaßnahmen nachweisen müssen.

Es gibt außerdem ein Scanner-Problem, das viele überrascht. Das Node.js-Projekt vergibt nun selbst CVEs für Versionen, deren Lebenszyklus abgelaufen ist (End-of-Life, EOL). Diese werden unter der CWE-1104 („Verwendung nicht mehr gepflegter Komponenten von Drittanbietern“) als „nicht unterstützt“ eingestuft. Node.js 18 kann daher in Tools wie npm audit oder Snyk allein aufgrund des abgelaufenen Lebenszyklus als Fehler angezeigt werden, unabhängig von einzelnen Fehlern.

Falls Sie in den Prüfungsumfang fallen: Entscheiden Sie sich jetzt für einen Weg – Upgrade, kommerzielle Patches oder dokumentierte Ausgleichskontrollen. Alle drei Optionen sind vertretbar. Die Feststellung während der Prüfung vor Ort, dass Sie über keine davon verfügen, ist es hingegen nicht.

Abhängigkeiten und Störungen im Ökosystem

Moderne Node.js-Anwendungen stützen sich auf einen umfangreichen Abhängigkeitsbaum, und dieser Baum verändert sich ohne Vorwarnung. Pakete, Frameworks und Cloud-Dienste stellen alte Laufzeitumgebungen nach ihrem eigenen Zeitplan ein. AWS beispielsweise hat die Unterstützung für Node.js 18.x im AWS Cloud Development Kit am 30. November 2025 eingestellt, was die CDK-CLI, die Construct-Bibliothek und zugehörige Projekte wie JSII, Projen und CDK8s betrifft.

Das Muster ist vorhersehbar. Bei neuen Paketversionen werden ältere Node.js-Versionen nicht mehr unterstützt, sodass Teams Versionen festlegen, um den Betrieb aufrechtzuerhalten – und auch dieser festgelegte Versionsbaum wird schließlich nicht mehr unterstützt. Je länger man dabei bleibt, desto mehr technische Schulden sammeln sich an, bis für routinemäßige Updates zunächst ein Upgrade der Laufzeitumgebung erforderlich wird.

Beispiel: Ein Team, das eine Node.js 18-API betreibt, muss eine Sicherheitslücke in einer Logging-Bibliothek beheben. Die korrigierte Version erfordert Node.js 20 oder höher. Da das Upgrade der Laufzeitumgebung nicht geplant ist, bleibt das Team bei der anfälligen Version. Der Patch ist zwar vorhanden, kann aber dennoch nicht angewendet werden.

So sieht das EOL-Risiko in Wirklichkeit aus. Es tritt in der Regel eher über den Abhängigkeitsbaum als über die Laufzeitumgebung selbst auf.

Operatives Risiko und schwierigere Fehlersuche

Nach Ablauf der Lebensdauer stellt das Node.js-Projekt die Bereitstellung von Fehlerbehebungen und den technischen Support für die betreffende Version ein, und das Augenmerk der Community richtet sich fortan auf die weiterhin unterstützten Versionen.

Das hat konkrete Auswirkungen auf die Reaktion auf Vorfälle: Man muss das Problem ohne Hilfe aus dem Upstream-Bereich beheben. Stößt man auf einen echten Laufzeitfehler, gibt es keinen zurückportierten Fix, auf den man warten könnte, keine Einstufung durch den Betreuer und immer weniger Community-Diskussionen zu einer Version, die nur noch wenige Nutzer verwenden. Auch Profiler, Debugger und APM-Agenten unterstützen alte Laufzeiten nicht mehr, sodass die Tools, auf die man normalerweise zurückgreifen würde, möglicherweise nicht mehr funktionieren.

Planen Sie entsprechend: Wenn Sie vorerst bei Version 18 bleiben, sollten Sie bei allen Problemen auf Laufzeitebene mit einer längeren durchschnittlichen Lösungszeit rechnen und eine reproduzierbare 18.x-Debug-Umgebung bereithalten, damit Sie diese nicht erst mitten in einem Vorfall neu einrichten müssen.

Ihre Optionen nach dem Ende des Supportzyklus für Node.js 18

Da Node.js 18 nun nicht mehr vom Node.js-Projekt unterstützt wird, muss jedes Team eine Entscheidung treffen. Der Status quo ist eine der möglichen Optionen – er wird nur meist nirgendwo festgehalten, wodurch er zum Standard wird.

	Nichts tun	Auf eine unterstützte LTS-Version aktualisieren	Erweiterte Unterstützung
Anfänglicher Aufwand	Niedrig	Hoch	Niedrig
Wiederkehrender Aufwand	Überwachung, Risikoabzeichnung, Prüfungsnachweise	Keine nach der Umstellung	Niedrig
Sicherheitspatches	Keine	Offiziell und laufend	Laufend, für betroffene Sicherheitslücken
Sicherheitsrisiko	Wächst mit jedem Release	Niedrigster	Reduziert
Technische Schulden	Wächst	Freigegeben	Wächst immer noch
Am besten, wenn	Isoliert und kurz vor der Stilllegung	In diesem Quartal sind Kapazitäten vorhanden	Das Upgrade ist erst in zwei oder mehr Quartalen fällig

Nichts tun

In diesem Quartal ist es am günstigsten, alles beim Alten zu belassen, auf längere Sicht hingegen am teuersten. Wenn ein System stabil ist und alles reibungslos funktioniert, ist die Versuchung groß, es einfach so zu lassen, wie es ist.

Das muss nicht unbedingt die falsche Entscheidung sein. Ein Dienst, der wirklich isoliert ist, keine regulierten Daten verarbeitet und dessen Stilllegung in ein oder zwei Quartalen finanziell abgesichert ist, lohnt sich möglicherweise gar nicht erst für eine Migration.

Was diese Entscheidung falsch macht, ist, sie als kostenlos zu betrachten. Auch wenn Sie nichts unternehmen, entstehen Ihnen dennoch Kosten für die Überwachung von Sicherheitslücken, die Genehmigung der Risikoakzeptanz, die Dokumentation von Audits und eine schwächere Position, falls doch einmal etwas schiefgeht. Diese Arbeitsstunden sind real und fallen immer wieder an.

Entscheidungspunkt: Wenn der Dienst mit dem Internet verbunden ist oder in den Prüfungsumfang fällt, kommt diese Option nicht in Frage. Wenn er isoliert ist und zur Stilllegung vorgesehen ist, dokumentieren Sie die Risikoakzeptanz formell und widmen Sie sich nützlicheren Aufgaben.

Upgrade auf eine unterstützte LTS-Version

Ein Upgrade ist die einzige Möglichkeit, das Problem endgültig zu beheben, anstatt es nur zu umgangen. Ab August 2026 haben Sie folgende Wahlmöglichkeiten:

• Node.js 24 (Krypton) – Aktive LTS-Version, Ende der Lebensdauer am 30. April 2028. Die Standardversion für die meisten Teams.
• Node.js 22 (Jod) – seit dem 21. Oktober 2025 in der LTS-Wartungsphase, Ende der Lebensdauer am 30. April 2027. Nur kritische Fehlerbehebungen und Sicherheitsupdates.
• Node.js 26 – derzeit in der „Current“-Reihe, die im Oktober 2026 in den Status „Active LTS“ übergehen soll, mit einem geplanten Ende der Lebensdauer am 30. April 2029.

 

Beachten Sie die Falle in dieser Liste. Node.js 22 scheint auf den ersten Blick die konservative Wahl zu sein, doch die aktive LTS-Phase ist bereits abgelaufen und es bleibt nur noch weniger als ein Jahr Support. Eine Migration von 18 auf 22 würde also bedeuten, dass Sie diesen Vorgang vor April 2027 erneut durchführen müssten. Sofern nichts in Ihrem Abhängigkeitsbaum 24 ausdrücklich blockiert, lohnt sich der Aufwand für einen Wechsel auf 22 nicht.

Durch ein Upgrade wird der offizielle Sicherheitssupport wiederhergestellt und Sie kehren zu einer Laufzeitumgebung zurück, auf die das breitere Ökosystem weiterhin ausgerichtet ist. Das lässt sich allerdings nicht an einem Nachmittag erledigen. Der Wechsel von 18 auf 24 umfasst zwei LTS-Linien und mehrere V8-Hauptversionen: Native Module müssen für die neue ABI neu kompiliert werden, node-gyp-Builds und vorgefertigte Binärdateien müssen überprüft werden, und die offiziellen Linux-Builds erfordern eine neuere glibc als die Node.js-18-Builds – genug, um ältere Distributionen ohne Änderung des Base-Images auszuschließen. Planen Sie einen vollständigen Testzyklus in der Staging-Umgebung ein, anstatt nur eine Versionserhöhung in der CI durchzuführen.

Profi-Tipp: Überspringen Sie Node.js 20. Da dessen Lebensdauer am 30. April 2026 endet, wäre ein Wechsel dorthin lediglich ein Seitenschritt auf eine andere, nicht mehr unterstützte Laufzeitumgebung. Sollte Ihre Migration erst nach dem Eintritt von Node.js 26 in den LTS-Status im Oktober 2026 erfolgen, bietet Version 26 den längsten geplanten Supportzeitraum – wägen Sie dies jedoch gegen die längere Produktionserfahrung und die breitere Unterstützung von Abhängigkeiten bei Version 24 ab. Denken Sie in jedem Fall daran, dass das Projekt darauf hinweist, dass sich die Zeitplanangaben ändern können.

TuxCare's unendlicher Lebenszyklus-Support

Nicht jedes System lässt sich innerhalb des Projektzeitplans aktualisieren. Lange Validierungszyklen, Genehmigungsverfahren für Änderungen, zertifizierte Software-Stacks und von Anbietern bereitgestellte Anwendungen verschieben den realistischen Termin um ganze Quartale statt nur um Wochen.

Mit dem „Endless Lifecycle Support“ von TuxCareerhält Node.js 18 auch nach dem offiziellen Ende des Lebenszyklus weiterhin Sicherheitspatches für abgedeckte Sicherheitslücken. Die Patches werden ohne Änderungen am Anwendungscode bereitgestellt, was diesen Ansatz für Teams praktikabel macht, die eine Anwendung derzeit nicht neu zertifizieren können. TuxCare deckt Node.js 12, 14, 16, 18 und 20 ab.

Betrachten Sie es eher als Zwischenstation denn als Endziel. Es befasst sich mit dem Aspekt der Patches und des Schwachstellenmanagements. Es verhindert jedoch nicht, dass sich Ihr Abhängigkeitsbaum weiter vergrößert oder Ihre technischen Schulden weiter ansteigen, und das Upgrade muss letztendlich trotzdem noch erfolgen.

Entscheidungspunkt: Wenn Sie das Upgrade realistischerweise noch in diesem Quartal bereitstellen können, führen Sie das Upgrade durch und überspringen Sie die Überbrückungslösung. Liegt der Termin zwei oder mehr Quartale in der Zukunft oder befinden Sie sich im Prüfungsumfang und können keine Patches installieren, überbrücken Sie die Lücke und stellen Sie die Finanzierung der Migration sicher.

Sichern Sie Ihre Node.js 18-Workloads mit TuxCare

Node.js 18 hat sich nicht verändert. Geändert hat sich jedoch der Supportstatus. Dieselbe Binärdatei, die im April 2025 noch eine gepflegte Laufzeitumgebung war, ist nun die älteste, nicht mehr gepflegte Komponente in Ihrer Anwendung und nimmt jedes Mal, wenn das Projekt ein Sicherheitsupdate veröffentlicht, neue, noch nicht behobene Sicherheitslücken auf.

Das Problem dabei ist, dass die naheliegende Lösung eine falsche Antwort beinhaltet. Node.js 22 ist der intuitive nächste Schritt nach Version 18 und derjenige, der am wenigsten Zeit kostet. Node.js 24 ist für die meisten Teams das richtige Ziel, stellt aber auch die anspruchsvollere Migration dar. Genau in dieser Lücke zwischen der einfachen und der richtigen Antwort kommt der erweiterte Support ins Spiel.

Für Unternehmen, die dieses Ziel nicht sofort erreichen können, bietet der „Endless Lifecycle Support“ für Node.js sorgt dafür, dass Node.js 18-Workloads vor bekannten Sicherheitslücken geschützt bleiben, während die Migration ordnungsgemäß geplant und getestet wird – ganz ohne Änderungen am Anwendungscode.

Wenn Sie noch Node.js 18 verwenden, sollten Sie sich in diesem Quartal für einen Weg entscheiden: Upgrade, Überbrückungslösung oder bewusste Akzeptanz des dokumentierten Risikos. Die einzige Option, die mit der Zeit immer teurer wird, ist, sich gar nicht zu entscheiden.

Häufig gestellte Fragen zum Ende des Supports für Node.js 18