Node.js 20 ist am Ende: Warum das Oktober-Update zeigt, dass du jetzt wechseln musst

Node.js 20 bekommt seit dem 30. April 2026 keine Sicherheitsupdates mehr. Das Security Release vom 21. Oktober 2026 macht das sehr konkret: Es behebt zehn Lücken, vier davon mit hohem Schweregrad, und eine davon erlaubt laut Node.js-Projekt Remote Code Execution. Fixes gibt es für Node 22, 24 und 26. Wer noch Node 20 oder älter betreibt, bleibt verwundbar. Die Lösung ist ein Upgrade auf eine unterstützte Version, nicht ein Workaround.

Dieser Artikel zeigt, welche Versionen noch unterstützt werden, was im Oktober-Update steckt und wie du den Wechsel sauber planst.

Welche Node.js-Versionen werden noch unterstützt?

Stand Oktober 2026 sieht der Release-Plan so aus:

Version	Status	End of Life
Node.js 18	End of Life	30.04.2025
Node.js 20	End of Life	30.04.2026
Node.js 22	Maintenance LTS	30.04.2027
Node.js 24	LTS	30.04.2028
Node.js 25	End of Life	01.06.2026
Node.js 26	Current, LTS ab 28.10.2026	30.04.2029

Wichtig ist eine Regel, die viele unterschätzen: Das Node.js-Projekt behandelt Release-Linien nach dem End of Life bei jeder neuen CVE automatisch als betroffen. Es prüft nicht mehr einzeln, ob eine Lücke dort auch greift. Für dich heißt das: Jede neue Sicherheitsmeldung betrifft deine alte Version, und es kommt kein Patch.

Ab Node.js 27 ändert sich außerdem das Modell. Es gibt nur noch einen Major-Release pro Jahr, jede Version wird LTS, die Unterscheidung zwischen geraden und ungeraden Versionen entfällt. Der Support läuft insgesamt 36 Monate. Das macht die Planung einfacher, ändert aber nichts an der Grundregel: Wer nach dem End of Life weiterfährt, fährt ohne Sicherheitsgurt.

Was steckt im Security Release vom 21. Oktober 2026?

Das Oktober-Update behebt zehn CVEs. Vier davon sind als hoch eingestuft:

• CVE-2026-111497: Out-of-bounds-Write in Brotli. Das Node.js-Projekt schreibt, die Lücke „permits remote code execution“.
• CVE-2026-105482: Problem in dns.resolve im Umgang mit NUL-Zeichen.
• CVE-2026-105483 und CVE-2026-106069: Umgehung der TLS-Hostname-Prüfung.

Behoben sind die Lücken in Node.js 22.23.4, 24.22.1 und 26.12.1. Zusätzlich wurde die CA-Liste aktualisiert, nachdem eine Intermediate-CA von eMudhra kompromittiert worden war.

Die Brotli-Lücke betrifft übrigens nicht nur Node.js. PHP hat am 26. Oktober 2026 neue Windows-Builds mit Brotli 1.2.1 gegen dieselbe CVE veröffentlicht. Eine Lücke in einer Bibliothek trifft also oft mehrere Plattformen gleichzeitig.

Ist das ein Einzelfall?

Nein. 2026 gab es bereits mehrere Security Releases mit hohen Lücken:

• 24. März 2026: unter anderem CVE-2026-21710 (DoS über __proto__-Header). Das war der letzte Fix für Node 20.
• 18. Juni 2026: 12 CVEs, darunter ein WebCrypto-DoS und ein TLS-Wildcard-Bypass.
• 29. Juli 2026: 11 CVEs, darunter zwei Use-after-free-Lücken in HTTP/2 und eine Lücke im Permission Model.
• 21. Oktober 2026: 10 CVEs, siehe oben.

Ungefähr jedes Quartal kommt also ein Release mit hohen Lücken. Ein Server, der ein Jahr lang nicht aktualisiert wird, sammelt in dieser Zeit mehrere bekannte Schwachstellen ein.

Reicht es, Node.js zu aktualisieren?

Nein. Die Laufzeit ist nur eine Schicht. Die Frameworks darüber haben eigene Lücken, und die waren zuletzt teils schwerer als die in Node.js selbst.

React und Next.js. Am 3. Dezember 2025 wurde „React2Shell“ bekannt, CVE-2025-55182. Die Lücke in React Server Components erlaubte Remote Code Execution ohne Login und wurde mit CVSS 10.0 bewertet. Laut Microsoft wurde sie aktiv ausgenutzt, unter anderem zum Einschleusen von Coinminern. Next.js veröffentlicht seit Juli 2026 angekündigte, monatliche Security Releases. Allein das Update vom 14. Oktober 2026 behebt zwei kritische RCE-Lücken. Sicher sind die Versionen 16.4.1 und 15.5.28.

Express-Umfeld. Express selbst hatte 2026 kein Security Release. Die Pakete drumherum schon: Am 31. August 2026 kamen unter anderem multer 2.3.0 mit drei hohen Lücken, hbs 4.3.0 mit einer XSS-Lücke und morgan 1.12.0. Viele Anwendungen nutzen genau diese Pakete für Uploads, Templates und Logs.

Ein Upgrade muss deshalb immer drei Ebenen umfassen: Node.js, das Framework und die Abhängigkeiten.

Wie gehst du das Upgrade an?

Ein Wechsel von Node 20 auf 24 oder 26 ist in den meisten Projekten gut planbar. So gehen wir dabei vor:

1. Bestand aufnehmen. Welche Server, Container und Build-Pipelines laufen mit welcher Version? Oft steckt Node 20 nicht nur auf dem Server, sondern auch im Dockerfile, in der CI und in Hilfsskripten.

node --version
grep -rn "node:20\|node-version: 20" Dockerfile* .github/ 2>/dev/null

2. Zielversion festlegen. Für neue Projekte empfehlen wir Node 26, weil es bis April 2029 unterstützt wird. Für bestehende Projekte mit vielen alten Abhängigkeiten ist Node 24 oft der ruhigere Schritt.

3. Abhängigkeiten prüfen. Native Module und alte Pakete sind die häufigste Bremse.

npm outdated
npm audit

4. Lokal und in der CI testen. Die Tests laufen gegen die neue Version, bevor irgendetwas live geht. Fehlen Tests, ist das der richtige Moment, wenigstens die wichtigsten Abläufe abzusichern.

5. Framework mitziehen. Next.js, Express-Middleware und Co. kommen im selben Zug auf den aktuellen, gepatchten Stand.

6. Schrittweise ausrollen. Erst Staging, dann Produktion, mit einem klaren Weg zurück.

7. Update-Routine einführen. Das wichtigste Ergebnis ist nicht das eine Upgrade, sondern ein fester Rhythmus. Security Releases von Node.js und Next.js sind angekündigt. Wer sie im Kalender hat, patcht in Tagen statt in Monaten.

Was gilt für PHP-Anwendungen?

Das gleiche Prinzip. PHP 8.1 ist seit Ende 2025 ohne Sicherheitsupdates, PHP 8.2 folgt am 31. Dezember 2026. Wie dringend das ist, hat die Lücke „PHP2Shell“ im Oktober 2026 gezeigt. Mehr dazu in unseren Artikeln zu PHP2Shell und zum Support-Ende von PHP 8.2. Und weil viele Angriffe inzwischen über Pakete statt über die Laufzeit kommen, lohnt sich auch ein Blick auf Supply-Chain-Angriffe über npm und Composer.

Wer Software für andere herstellt, hat seit September 2026 außerdem neue Pflichten: Aktiv ausgenutzte Schwachstellen müssen gemeldet werden. Was das heißt, steht im Artikel zum Cyber Resilience Act.

Wie HR CodeLabs dir hilft

Wir entwickeln selbst mit Node.js und PHP und kennen die typischen Stolperstellen beim Upgrade. Je nachdem, wo du stehst, unterstützen wir dich so:

• Sicherheits-Check: Wir prüfen deine Node.js- und PHP-Anwendungen und Server auf veraltete Versionen, bekannte Lücken und riskante Abhängigkeiten. Du bekommst eine klare Liste, was dringend ist und was warten kann.
• Update- & Wartungsservice: Wir spielen Security Releases zeitnah ein, überwachen deine Systeme und halten Laufzeit, Framework und Pakete aktuell.
• Migration alter Versionen: Wir heben Node 18 oder 20 auf eine unterstützte Version und ziehen Framework und Abhängigkeiten mit. Getestet und mit Weg zurück.
• Notfallhilfe nach Angriff: Wenn eine Lücke schon ausgenutzt wurde, helfen wir beim Eingrenzen, Bereinigen und Absichern.

Mehr dazu auf der Seite Sicherheit & Wartung. Oder du buchst direkt ein kostenloses Erstgespräch und wir schauen gemeinsam, welche Version bei dir läuft und wie der Weg nach vorn aussieht.