Technischer Support
Dokumentation
Anmeldung
Kontakt
Gehen Sie direkt zu einer KI-Zusammenfassung dieses Blogbeitrags 
Wichtigste Erkenntnisse
- Sobald eine Node.js-Version das Ende ihres Lebenszyklus erreicht hat, prüft der Upstream-Entwickler nicht mehr, ob neue Sicherheitslücken diese Version betreffen.
- Ab Node.js 27 veröffentlicht das Projekt einmal pro Jahr eine Hauptversion, und jede Release-Reihe wird zur LTS-Version.
- KI-Tools entdecken echte Node.js-Fehler, doch doppelte Meldungen überfordern mittlerweile die Freiwilligen, die für die Triage zuständig sind.
- Teams, die das Upgrade nicht termingerecht durchführen können, benötigen eine gepatchte Laufzeitumgebung und dürfen nicht darauf hoffen, dass nichts bekannt wird.
Eine Node.js-Anwendung läuft nicht weiter, wenn ihre Version das Ende ihrer Lebensdauer erreicht hat. Das Upstream-Projekt kümmert sich lediglich nicht mehr um sie. Und wie James Snell, Mitglied des Node.js Technical Steering Committee, kürzlich in einem Kamingespräch mit TuxCare erklärte, ist dieser Unterschied viel größer, als es zunächst klingt.
„Keine Backports, keine Fehlerbehebungen“, sagte er. Wenn ein neuer Bericht über eine Sicherheitslücke eingeht, prüft das Team nicht einmal, ob diese eine EOL-Produktreihe betrifft. Ein Dienst kann in der Produktion vollkommen einwandfrei erscheinen, während die Sicherheitsarbeiten im vorgelagerten Bereich still und leise ohne ihn weitergegangen sind.
Das war einer von mehreren offenen Momenten in „Keepers of the Runtime“, in dem sich Snell mit Chris DeMars, Senior Developer Advocate bei TuxCare, unterhielt. Keine Folien, keine Produktdemo. Sie sprachen darüber, warum Node.js auf eine Hauptversion pro Jahr umstellt, welche Auswirkungen KI-generierte Sicherheitsberichte auf ein ehrenamtliches Sicherheitsteam haben und wie viel menschliche Arbeit hinter einem auf den ersten Blick routinemäßigen Sicherheitsupdate steckt. Hier sind die wichtigsten Punkte, wenn Sie Node.js in der Produktion einsetzen – es lohnt sich jedoch, sich eine halbe Stunde Zeit zu nehmen, um die vollständige Aufzeichnung anzusehen.
Das Ende des Lebenszyklus von Node.js bedeutet das Ende der Sicherheitsarbeit auf Upstream-Ebene
Snells Beschreibung des „End of Life“ war unverblümt. Sobald der Support für eine Hauptversion ausläuft, werden keine weiteren Updates mehr dafür bereitgestellt. Keine Sicherheitspatches, keine gewöhnlichen Fehlerbehebungen, keine Backports aus neueren Zweigen. „Andere tun das vielleicht, aber wir werden es nicht tun“, sagte er in Bezug auf das Testen alter Versionen anhand neuer Fehlermeldungen. „Sobald das ‚End of Life‘ erreicht ist, verschwindet es aus unserem Blickfeld.“
Die projektinternen Leitlinien zu EOL-Sicherheitslücken ziehen dieselbe Grenze. Eine alte Version kann durchaus von einer Sicherheitslücke betroffen sein, die in einer weiter gepflegten Version bekannt gegeben wurde, doch der Upstream-Entwickler wird den alten Zweig in der Regel nicht untersuchen, um die Auswirkungen zu bestätigen, geschweige denn einen Fix erstellen.
Überlegen Sie sich, was das für Ihren Scanner bedeutet. Seit 2025 werden in neuen Node.js-CVEs EOL-Zeilen standardmäßig als betroffen aufgeführt, sofern dem Projekt nichts Gegenteiliges bekannt ist. Dadurch bleibt die Warnung sichtbar, aber niemand aus dem Upstream-Bereich hat die Schwachstelle in Ihrer Version bestätigt, und niemand aus dem Upstream-Bereich arbeitet an einer Korrektur.
Eine EOL-Laufzeitumgebung steht auch nicht für sich allein. Node.js bündelt Komponenten wie V8 und OpenSSL, und Snell wies darauf hin, dass ständig Zero-Day-Schwachstellen in V8 auftauchen, darunter auch Sandbox-Escapes. Nicht jede browserbasierte V8-Sicherheitslücke wirkt sich auf Node.js aus, aber jemand muss herausfinden, welche davon dies tun – und bei einer EOL-Version ist dieser Jemand nicht der Upstream-Entwickler. Gleichzeitig stellen Bibliotheken und Tools die Unterstützung für ältere Node.js-Versionen immer häufiger ein, sodass ein aufgeschobenes Upgrade von Monat zu Monat schwieriger wird.
Das bedeutet jedoch nicht, dass jede EOL-Bereitstellung automatisch ausnutzbar ist. Die Gefährdung hängt von der jeweiligen Schwachstelle, der Konfiguration und den erreichbaren Codepfaden ab. Was sich bei EOL ändert, ist, dass keine Antworten und Patches mehr vom Upstream-Anbieter kommen, wodurch Ihr Team genau an dem Punkt, an dem sich seine Optionen verengen, mit einem höheren Untersuchungsaufwand konfrontiert ist.
Warum Upstream alte Versionen nicht länger aufrechterhalten wird
Es kommt vor, dass Nutzer die Entwickler bitten, eine alte Version noch etwas länger zu unterstützen. Die Antwort hängt letztlich von Menschen und Maschinen ab. Node.js wird in erster Linie von Freiwilligen gepflegt. Einige Mitwirkende werden zwar gesponsert, doch laut Snell erledigt fast jeder, der Releases veröffentlicht, Backports erstellt und Beiträge leistet, dies in seiner Freizeit. „Wir werden nicht einfach alles auf unbestimmte Zeit unterstützen“, sagte Snell. „Das können wir nicht. Das ist unmöglich.“
Dann ist da noch CI. Laut Snell deckt ein vollständiger CI-Lauf etwa 55 Kombinationen aus Plattformen, Architekturen und Betriebssystemen ab, mit jeweils etwa 7.800 Tests, und ein einzelner Lauf kann bis zu einer Stunde dauern. Unternehmen stellen diese Infrastruktur zur Verfügung, und ihre Kapazität ist begrenzt. Multipliziert man das mit jeder alten Release-Reihe, geht die Rechnung schnell nicht mehr auf. Wie Snell es ausdrückte: „Das Ende der Lebensdauer ist das Ende der Lebensdauer, weil wir physisch einfach nicht die Ressourcen aufbringen können, um sie weiter zu warten.“
Das ist ein berechtigter Standpunkt; dagegen lässt sich kaum etwas einwenden. Allerdings entsteht dadurch eine Lücke, und diese Lücke betrifft alle, die noch die alte Version nutzen.
Warum Node.js auf eine Hauptversion pro Jahr umstellt
Dasselbe Kapazitätsproblem erklärt auch den neuen Veröffentlichungskalender. Der alte Zeitplan war ein Kompromiss, der im Zuge der io.js-Wiedervereinigung entstanden war: kurzlebige Veröffentlichungen mit ungeraden Nummern, die nur etwa acht Monate lang unterstützt wurden, damit Autoren von Bibliotheken und Frameworks sehen konnten, was auf sie zukam, sowie Veröffentlichungen mit geraden Nummern, die für Unternehmen zu LTS-Versionen wurden.
Die Download-Daten aus zehn Jahren zeichneten ein anderes Bild. „Die kurzfristigen Versionen hat eigentlich niemand genutzt“, sagte Snell. Unternehmen führten bereits etwa einmal im Jahr ein Upgrade durch – wenn überhaupt. Die Betreuer mussten unterdessen manchmal vier oder fünf aktive Release-Zweige gleichzeitig unter einen Hut bringen, und jeder Sicherheitspatch musste durch Zweige zurückverfolgt werden, die sich in unterschiedliche Richtungen entwickelt hatten.
Gemäß dem offiziellen Node.js-Release-Plan ist Node.js 27 die erste Version nach dem neuen Modell. Jedes Jahr erscheint im April eine Hauptversion, die im Oktober desselben Jahres zum LTS-Status erhoben wird, sodass jede Release-Reihe letztendlich den LTS-Status erhält. Ein Alpha-Kanal übernimmt die Rolle der frühen Testphase, die früher von ungeraden Versionen übernommen wurde, und nach sechs Monaten im Alpha-Status erhält jede Reihe 36 Monate Support, gerechnet ab der ersten „Current“-Version bis zum Ende der Lebensdauer. Snells Zusammenfassung der Vorteile war einfach: Es müssen weitaus weniger Release-Reihen verwaltet werden, da in der Regel nur etwa drei gleichzeitig aktiv sind.
| Freigabezeile | Alpha beginnt | Erste Veröffentlichung | Wechselt zu LTS | Ende des Lebens |
|---|---|---|---|---|
| Node.js 26 (die letzte Version nach dem alten Modell) | Nicht zutreffend | Mai 2026 | Oktober 2026 | April 2029 |
| Node.js 27 | Oktober 2026 | April 2027 | Oktober 2027 | April 2030 |
| Node.js 28 | Oktober 2027 | April 2028 | Oktober 2028 | April 2031 |
Wenn Ihr Team bereits ausschließlich LTS-Versionen einsetzt, ändert sich außer der Versionsnummerierung kaum etwas. Wenn Sie Produkte auf Basis von Node.js entwickeln, lautete Snells Rat, nicht bis April zu warten, um herauszufinden, was nicht mehr funktioniert. Wesentliche Änderungen und veraltete Funktionen werden veröffentlicht am main Ständig. Fügen Sie in der CI einen Smoke-Test-Job hinzu, der auf anstehende Alpha-Builds angewendet wird, ohne Merge-Vorgänge zu blockieren, und sorgen Sie dafür, dass jemand die Ergebnisse tatsächlich liest. Alpha-Builds sind zwar nicht für den Produktiveinsatz gedacht, aber ein Problem drei oder vier Monate früher zu entdecken, ist weitaus kostengünstiger, als es erst während eines Migrationsfensters zu entdecken.
Was passiert zwischen einem Node.js-Sicherheitsbericht und einer Fehlerbehebung?
Node.js nimmt Sicherheitslückenmeldungen über HackerOne entgegen. Ein Triage-Mitarbeiter prüft zunächst, ob das gemeldete Verhalten tatsächlich vorliegt, und entscheidet dann, ob es eine im Bedrohungsmodell des Projekts definierte Sicherheitsgrenze überschreitet.
Diese zweite Einschätzung wird leicht übersehen. Das Vertrauensmodell von Node ist sehr einfach: Wenn der Code läuft, ist er vertrauenswürdig. Ein Segfault, den man nur durch die lokale Ausführung des eigenen Codes auslösen kann, ist wahrscheinlich ein gewöhnlicher Fehler, der öffentlich behoben wird. Etwas, das über nicht vertrauenswürdige Remote-Eingaben erreichbar ist, wie beispielsweise die Remote-Codeausführung oder ein Remote-Denial-of-Service, wird als Sicherheitslücke behandelt.
Diese Korrekturen werden in einem privaten Fork von Node entwickelt, geprüft und integriert, und das Sicherheitsupdate wird von dort aus veröffentlicht. Erst nach der Veröffentlichung werden die Änderungen in das öffentliche Repository übernommen. Dadurch wird die Zeitspanne zwischen der Offenlegung und der Verfügbarkeit eines Patches für unterstützte Produktlinien nahezu auf null reduziert, was jedoch auch bedeutet, dass die Uhr für Sie bereits in dem Moment zu ticken beginnt, in dem eine Sicherheitsmitteilung veröffentlicht wird. Die Veröffentlichung vom 21. Oktober 2026 ist ein gutes Beispiel – zehn CVEs in den Produktlinien 22.x, 24.x und 26.x, von denen vier als „High“ eingestuft wurden. Der Artikel von TuxCare „10 Node.js-CVEs, ein Brotli-RCE und was zu tun ist, wenn Ihre Version das EOL erreicht hat“ erläutert, was dies für alle Nutzer einer EOL-Produktlinie bedeutet. Auch die nächste Runde steht bereits an. Node.js hat ein weiteres Sicherheitsupdate für den 11. November 2026 oder kurz danach angekündigt, das erneut die Versionsreihen 22.x, 24.x und 26.x abdeckt, wobei das schwerwiegendste Problem als „High“ eingestuft wird. In der Sicherheitsmitteilung wird ausdrücklich darauf hingewiesen, dass EOL-Versionen bei jedem Sicherheitsupdate betroffen sind.
KI entdeckt echte Fehler und überflutet die Triage-Warteschlange
An dieser Stelle wurde Snell am lebhaftesten. Das KI-gestützte Scannen funktioniert. „Es findet definitiv echte Fehler“, sagte er. Die Genauigkeit ist nicht das Hauptproblem. Das Problem ist das Volumen.
Forscher, die ähnliche Tools einsetzen, entdecken denselben Fehler oft zur gleichen Zeit und melden ihn unabhängig voneinander. Snell beschrieb, dass er 10 oder 20 Meldungen zu einem Problem erhielt, wobei während der Behebung weitere hinzukamen und auch nach der Offenlegung noch eine lange Nachlaufphase mit vereinzelten Meldungen folgte. Während einer kürzlich durchgeführten Triage-Phase schätzte er, dass „wahrscheinlich neun von zehn Meldungen Duplikate waren“ – seine Schätzung basierte auf diesem Arbeitsaufkommen, nicht auf einer gemessenen Quote.
Das Sicherheitsupdate der OpenJS Foundation für das zweite Quartal 2026 bestätigt diesen Trend. In den zwei Jahren vor diesem Quartal gingen bei Node.js 352 HackerOne-Meldungen ein. Im Februar 2026 stieg die Zahl der Meldungen dann um das 4,6-Fache, nachdem KI-gestützte Scan-Tools eingeführt worden waren, und allein im März gab es 65 Meldungen. Zum Zeitpunkt des Chats, so Snell, habe Node.js im Jahr 2026 bereits Korrekturen für mehr als 50 Sicherheitslücken veröffentlicht – ein Rekord.
Sein Rat an die Forscher war praxisorientiert. Lesen Sie die Sicherheitsrichtlinie und das Bedrohungsmodell des Projekts. Durchsuchen Sie die öffentlich zugänglichen Berichte auf HackerOne, um zu prüfen, ob das Problem bereits behoben wurde. Und wenn Ihr Tool 20 potenzielle Schwachstellen findet, reichen Sie nicht 20 Berichte auf einmal ein. Ordnen Sie diese nach Priorität und melden Sie die kritischsten zuerst.
Die Arbeit, die in den Versionshinweisen nicht erwähnt wird
Snell kam nicht aufgrund eines groß angelegten Plans zu Node.js. Im Jahr 2013, als er bei IBM tätig war, entdeckte er einen Fehler, bei dem Node eine verfälschte HTTP-Methode wie P?T als echte Methode anzuerkennen, anstatt sie abzulehnen. Da es noch keinen Prozess für Sicherheitsmeldungen gab, eröffnete er ein öffentliches Ticket, bekam zu hören, er verstehe nicht, wie diese Art von Software funktioniere, behob das Problem selbst und wandte sich anderen Aufgaben zu. Der io.js-Fork holte ihn zurück, als IBM einen technischen Leiter für alle Node-Belange suchte, und er trat etwa im März 2015 dem TSC bei.
Die tägliche Arbeit ist weniger glamourös als der Titel vermuten lässt. Der Morgen beginnt mit einer Stunde oder mehr GitHub-Benachrichtigungen, manchmal sind es 800 oder 900 pro Tag. Die Code-Reviews nehmen noch mehr seiner Zeit in Anspruch. „Ich lese jede Zeile jedes Pull-Requests, selbst bei den umfangreichen“, sagte er, egal ob es sich um zehn oder 20.000 Zeilen handelt – oft in zwei oder drei Durchgängen. KI schreibt mittlerweile den Großteil seiner Tests, hat aber sein Urteilsvermögen nicht ersetzt.
Snell widersprach zudem der Vorstellung, dass Node.js über eine Produkt-Roadmap verfüge. „Es gibt keinen Produktmanager. Es gibt nicht einmal einen Projektmanager.“ Niemand kann sich eine Funktion in Node erkaufen. Sobald die CI-Prüfung bestanden ist, kann ein Pull-Request nach mindestens 48 Stunden mit zwei Genehmigungen oder nach einer Woche mit einer Genehmigung übernommen werden, sofern niemand Einwände erhebt. Wenn man also möchte, dass Node etwas kann, lautet sein Rat: Eröffne einen PR und setze es selbst um, anstatt zu verlangen, dass Freiwillige es kostenlos entwickeln.
Was dies für Teams bedeutet, die noch ältere Node.js-Versionen verwenden
Beginnen Sie mit dem, was tatsächlich im Einsatz ist. Nicht mit dem, was im aktuellen Dockerfile steht oder was im Migrations-Ticket angegeben ist, sondern mit den Node.js-Versionen, die in der Produktion laufen – einschließlich der Dienste, an denen schon lange niemand mehr etwas geändert hat. Gleiche diese mit dem Node.js-Release-Zeitplan ab, kennzeichne diejenigen, deren Lebensdauer bereits abgelaufen ist, und weise jedem einen Verantwortlichen zu. Node.js 20 hat am 30. April 2026 das Ende seiner Lebensdauer erreicht, und Node.js 22 folgt im April 2027 – es handelt sich also nicht nur um ein Problem für Teams, die mit veralteten Versionen arbeiten.
Wenn Sie jetzt ein Upgrade durchführen können, tun Sie es. Eine unterstützte LTS-Version ist die sauberste Lösung, und regelmäßige Upgrades während des Betriebs sind besser als alle paar Jahre eine Notfallsituation.
Manche Anwendungen können diesen Zeitplan nicht einhalten. Stellen Sie sich einen Zahlungsdienst vor, der an Node.js 18 gebunden ist, weil ein natives Add-on unter der neueren V8-Version nicht mehr funktioniert und die Migration von einer Neuprogrammierung durch den Anbieter abhängt, die erst in zwei Quartalen erfolgen soll. In solchen Fällen ist „Wir werden später aktualisieren“ kein Sicherheitskonzept, es sei denn, für die alte Laufzeitumgebung gibt es weiterhin eine Möglichkeit, Fehlerbehebungen zu erhalten.
Genau diese Lücke schließt der „Endless Lifecycle Support“ (ELS) von TuxCare für Node.js. Als Teil des ELS für Laufzeiten portiert er Sicherheitskorrekturen im Rahmen des SLA auf die abgedeckten Node.js-Versionen, deren Lebenszyklus bereits beendet ist (EOL), und stellt sie als Paket-Updates bereit. So laufen Ihre Anwendungen weiterhin auf der Laufzeitumgebung, für die sie entwickelt wurden, während Sie die Migration nach Ihrem eigenen Zeitplan abschließen. Starten Sie nach einem Update einfach die betroffenen Node.js-Prozesse neu, damit sie die gepatchte Laufzeitumgebung übernehmen. Die Abdeckung reicht bis zurück zu Node.js 10 auf Enterprise Linux und umfasst auch Ubuntu, Debian und Alpine Linux, wobei die unterstützten Versionen je nach Betriebssystem variieren. Überprüfen Sie daher die Versionsmatrix in der Dokumentation. Dies erspart Ihnen nicht die Notwendigkeit, irgendwann ein Upgrade durchzuführen. Es deckt den Zeitraum zwischen dem Tag, an dem der Upstream die Fehlerbehebung für eine Version einstellt, und dem Tag ab, an dem Sie diese sicher aus dem Verkehr ziehen können.
Sie müssen auch nicht auf einen Anruf eines Vertriebsmitarbeiters warten. Kaufen Sie ELS für Runtimes online, installieren Sie es und bringen Sie Ihre EOL-Versionen von Node.js wieder auf den Patch-Stream.
Häufig gestellte Fragen
Was passiert, wenn eine Node.js-Version das Ende ihrer Lebensdauer erreicht?
Upstream stoppt alle Commits für diese Codezweig, einschließlich Sicherheitskorrekturen, und prüft nicht, ob neu gemeldete Sicherheitslücken diesen betreffen. Ab diesem Zeitpunkt liegt das Risiko beim Team, das diesen Codezweig betreibt.
Wann erscheint Node.js 27?
Die Alpha-Phase von Node.js 27 begann im Oktober 2026. Die erste „Current“-Version ist für April 2027 geplant, die Umstellung auf LTS soll im Oktober 2027 erfolgen und das Ende des Lebenszyklus ist für April 2030 vorgesehen.
Kann man Node.js 18 oder Node.js 20 auch nach Ablauf der Lebensdauer weiterhin nutzen?
Ja. Kommerzielle Support-Angebote wie der „Endless Lifecycle Support“ von TuxCare für Node.js stellen weiterhin Sicherheitspatches für die abgedeckten EOL-Versionen bereit, während Sie Ihr Upgrade planen – vorausgesetzt, Sie installieren die Updates und starten die betroffenen Prozesse neu.
Sehen Sie sich das gesamte Kamingespräch an
Die Aufzeichnung enthält die Beiträge, die in diesem Beitrag nicht erwähnt wurden, sowie die Live-Fragerunde zu doppelten Meldungen und zur Bindung von Freiwilligen. Sehen Sie sich „Keepers of the Runtime“ mit James Snell und Chris DeMars an.
Und falls ein Teil Ihres Stacks noch auf einer Node.js-Version läuft, für die Upstream-Entwickler keine Patches mehr bereitstellen, sollten Sie nicht auf den nächsten Sicherheitshinweis warten, bis die Entscheidung für Sie getroffen wird. Holen Sie sich ELS for Runtimes und sorgen Sie dafür, dass die abgedeckten Versionen weiterhin Sicherheitspatches erhalten, während Sie das Upgrade nach Ihrem eigenen Zeitplan durchführen.
