Node.js 20 ist End of Life: Risiken für Webanwendungen und der Weg auf Node 22 oder 24
Ihre Website läuft auf Node.js. Vielleicht wissen Sie es nicht einmal, weil die Technik im Hintergrund arbeitet. Node.js treibt Build-Prozesse, APIs und ganze Webanwendungen an. Für alle außer den Entwicklern bleibt das meist unsichtbar. Seit dem 30. April 2026 ist Node 20 end of life. Das bedeutet: keine Sicherheitsupdates mehr für eine wichtige Version. Viele Unternehmen betreiben sie noch im Produktivbetrieb.
Das klingt nach einem Detail für die IT-Abteilung. In Wirklichkeit geht es um ein Geschäftsrisiko. Wer mit einer End-of-Life-Version arbeitet, betreibt Software, die niemand mehr absichert. Neue Lücken werden gefunden, aber nicht mehr geschlossen.
Dieser Artikel zeigt, wo Node.js überall im Einsatz ist. Er erklärt, welche Risiken durch Node 20 end of life entstehen. Und er zeigt, welche Version jetzt das richtige Ziel für ein Upgrade ist.
Wo Node.js überall steckt, ohne dass es auffällt
Node.js ist eine Laufzeitumgebung für JavaScript außerhalb des Browsers. Sie führt JavaScript-Code auf einem Server oder in einem Build-Prozess aus. Nicht nur im Browser eines Besuchers.
Viele Unternehmen denken bei Node.js zuerst an eigene Backend-Anwendungen. Das ist nur ein Teil der Wahrheit.
Node.js läuft auch hinter den Kulissen von Frameworks wie Next.js oder Nuxt. Es treibt Build-Werkzeuge wie Webpack und Vite an. Es führt automatisierte Tests in der Entwicklungspipeline aus. Und es betreibt Serverless-Funktionen bei vielen Hosting-Anbietern.
Wer sein eigenes Backend nicht in Node.js geschrieben hat, kann trotzdem betroffen sein. Ein Blick in die Datei package.json zeigt oft schon die Antwort. Auch die CI/CD-Konfiguration verrät, welche Node-Version tatsächlich läuft. Der Befehl node -v auf dem Server liefert die Version direkt. Keine Dokumentation nötig. Auch im Dashboard vieler Hosting-Anbieter lässt sich die Node-Version direkt einsehen, meist unter den Projekteinstellungen.
Welche Risiken jetzt entstehen
Sicherheitslücken, die offen bleiben
Node.js baut auf der V8-JavaScript-Engine von Google auf. Eigene Module ergänzen das für Dateisystem und Netzwerk. In beiden Bereichen werden laufend neue Schwachstellen gefunden.
Für aktuelle Node-Versionen schließt das Node.js-Team diese Lücken zeitnah. Für Node 20 passiert das seit Ende April 2026 nicht mehr. Jede neu gefundene Lücke bleibt offen, dokumentiert und öffentlich einsehbar.
Automatisierte Scanner durchsuchen das Internet gezielt nach Servern mit veralteten Laufzeitumgebungen. Eine Anwendung muss nicht besonders wertvoll wirken, um ins Visier zu geraten. Es reicht, dass sie erreichbar ist.
Abhängigkeiten, die nicht mehr mitziehen
Node.js-Projekte bestehen aus vielen kleinen npm-Paketen. Paketpfleger testen neue Versionen meist nur gegen aktuell unterstützte Node-Versionen. Node 20 fällt aus diesem Kreis heraus.
Mit der Zeit lassen sich Pakete nicht mehr aktualisieren, ohne Fehler zu riskieren. Das trifft besonders Projekte, die ohnehin schon mit veralteten Abhängigkeiten arbeiten. Mehr dazu lesen Sie im Artikel zu npm-Paketen und Sicherheitsrisiken in JavaScript-Legacy-Projekten.
Ein zusätzliches Risiko entsteht, wenn ein kompromittiertes Paket unbemerkt in die Abhängigkeitskette gelangt. Solche Software supply chain Angriffe treffen veraltete Systeme besonders häufig. Dort schaut niemand mehr genau hin.
Hosting-Anbieter ziehen den Stecker
Viele Hosting-Plattformen und Cloud-Anbieter entfernen End-of-Life-Laufzeiten nach einer Übergangsfrist aus ihrem Angebot. Wer dann noch auf Node 20 setzt, wird zu einem ungeplanten Upgrade gezwungen.
Manche Anbieter kündigen das rechtzeitig per E-Mail an, andere nur über ein knappes Änderungsprotokoll. Ein Upgrade unter Zeitdruck ist selten ein gutes Upgrade. Tests fallen knapper aus, Fehler werden eher übersehen.
Node 22 oder Node 24: Welche Version jetzt sinnvoll ist
Node.js folgt einem festen Rhythmus. Alle zwei Jahre wird im Oktober eine neue Version zur Long Term Support-Version, kurz LTS. Was LTS genau bedeutet, erklären wir ausführlich im Artikel zu Long Term Support. Dort steht auch, warum im Betrieb nur solche Versionen laufen sollten.
Node 22 ist die etabliertere der beiden aktuellen LTS-Linien. Sie läuft bereits seit Oktober 2024. Sicherheitsupdates sind voraussichtlich bis ins Jahr 2027 eingeplant. Für Unternehmen, die einen bewährten, gut getesteten Pfad suchen, ist das der naheliegende Griff.
Node 24 ist die neuere Linie. Sie bringt zusätzliche Jahre an Support und profitiert von neueren Funktionen der V8-Engine. Wer ohnehin größere Änderungen am System plant, kann direkt auf Node 24 zielen. So spart er sich das nächste Upgrade.
Beide Versionen sind solide Ziele. Die Wahl hängt vom Zustand der Anwendung und von den verwendeten Paketen ab.
So läuft ein Node-Upgrade in der Praxis ab
Schritt 1: Bestandsaufnahme
Zuerst wird geklärt, wo genau Node 20 im Einsatz ist. Server, Build-Pipelines, Docker-Images und Hosting-Konfigurationen gehören alle auf die Liste.
Schritt 2: Kompatibilität prüfen
Jede neue Node-Version entfernt veraltete Funktionen und ändert Verhalten im Detail. Ein Blick in die offiziellen Änderungshinweise zeigt, welche Teile des eigenen Codes betroffen sein könnten. Paketabhängigkeiten werden auf Kompatibilität mit der Zielversion geprüft.
Schritt 3: Testumgebung aufbauen
Das Upgrade läuft zuerst in einer Testumgebung, nicht in der Produktion. Automatisierte Tests laufen gegen die neue Version. Fehlen Tests, lohnt es sich, zumindest die wichtigsten Abläufe vorher abzusichern.
Schritt 4: Stufenweise umstellen
Bei größeren Systemen empfiehlt sich ein gestaffeltes Vorgehen. Erst unkritische Dienste, dann die Kernanwendung. So bleibt jeder Fehler eingrenzbar.
Schritt 5: Go-Live und Beobachtung
Nach der Umstellung werden Fehler-Logs in den ersten Tagen aktiv beobachtet. So lassen sich Probleme früh erkennen, bevor sie Kunden bemerken.
Was kostet ein Node-Upgrade?
Das hängt stark vom Projekt ab. Ein schlankes API-Backend mit wenigen, aktuellen Abhängigkeiten lässt sich oft innerhalb weniger Tage umstellen.
Ein gewachsenes System mit vielen eigenen Modulen und alten Paketen braucht mehr Zeit. Hier zahlt sich eine genaue Analyse vor dem Projektstart aus, statt pauschal zu schätzen. Wer vorher weiß, welche Abhängigkeiten Probleme machen, vermeidet teure Überraschungen mitten im Projekt.
Wer seine Software laufend betreuen lässt, bekommt solche Upgrades oft automatisch mit. Sie laufen dann als Teil der Software-Wartung, nicht als separates Einzelprojekt.
Fazit: Node 20 end of life ist kein Grund zur Panik, aber ein Grund zum Handeln
Node 20 end of life bedeutet nicht, dass Ihre Anwendung morgen ausfällt. Es bedeutet, dass jeder weitere Monat ohne Sicherheitsupdates das Risiko erhöht.
Ein Upgrade auf Node 22 oder Node 24 lässt sich strukturiert planen. Dafür braucht es nur genug Vorlauf. Wer wartet, bis der Hosting-Anbieter oder ein Sicherheitsvorfall den Zeitpunkt vorgibt, hat weniger Kontrolle.
Sprechen Sie uns an. Das Erstgespräch ist kostenlos. Wir schauen uns Ihre Node-Version an und sagen Ihnen, was als nächstes sinnvoll ist.
