Noch auf Node.js 20? Das Sicherheitsupdate vom 11. November schützt Sie nicht

Node.js 20 geht am 11. November 2026 leer aus. Die Sicherheits-Releases decken ausschließlich 26.x, 24.x und 22.x ab, da Node.js 20 am 30. April 2026 sein End-of-Life erreicht hat. Ihr letzter Patch war Version 20.20.2 vom 24. März. Seitdem wurden 33 CVEs behoben, ohne dass ein 20.x-Build bereitgestellt wurde. Wechseln Sie noch diese Woche auf Version 24 oder 26.

Diese CVEs wurden im Rahmen dreier Sicherheitsupdates veröffentlicht, bei denen Node.js 20 unberücksichtigt blieb. Das vierte steht in wenigen Tagen an, und die Vorankündigung stuft das gravierendste Problem für jede unterstützte Versionslinie als HIGH ein.

Was es mit dem 11. November auf sich hat – und warum Node.js 20 leer ausgeht

Das Node.js-Projekt wird am oder kurz nach Mittwoch, dem 11. November 2026, neue Builds für 26.x, 24.x und 22.x bereitstellen. Bislang sind keine CVE-Details öffentlich; sie bleiben bis zur Veröffentlichung der Builds vertraulich. Unser Countdown-Leitfaden zum November-Release deckt die Runtime-Bestandsaufnahme und die Befehle für den Patch-Tag ab, weshalb dieser Beitrag darauf verzichtet.

Node.js 20 steht nicht auf der Liste, weil das Projekt dessen Wartung eingestellt hat. Die End-of-Life-Seite formuliert es unmissverständlich: Wenn neue Sicherheitsupdates Schwachstellen aufdecken, gilt: „Selbst wenn dieselbe Schwachstelle EOL-Release-Linien betrifft, wird es für diese keine neuen Releases geben.“

Der Sicherheitshinweis enthält einen weiteren Satz, der für Sie entscheidend ist: „End-of-Life-Versionen sind grundsätzlich betroffen, sobald ein Sicherheits-Release erscheint.“

Was Node.js 20 bisher verpasst hat

Seit Node.js 20 das End-of-Life erreicht hat, wurden drei Sicherheits-Releases herausgegeben. Keines davon enthält einen 20.x-Build.

Der Code, den diese Fehlerbehebungen betreffen, ist genau jener, den ein API-Server im Dauerbetrieb ausführt:

• TLS-Hostnamen-Prüfungen: Sowohl im Juni als auch im Oktober wurden Wege geschlossen, über die ein Zertifikat fälschlicherweise für den falschen Host akzeptiert wurde.
• HTTP/2: Zu den schwerwiegenden Fixes im Juli gehören ein Heap-Use-After-Free und ein Fehler, der zur Remote-Speichererschöpfung führen kann.
• DNS: Im Oktober wurde behoben, dass dns.resolve*() Hostnamen an einem NUL-Byte abschneidet, was eine Allowlist austricksen kann.
• Kompression: Im Oktober wurde ein Out-of-Bounds-Write im Brotli-Decoder behoben, der in einer Remotecodeausführung (RCE) enden kann. Dies behandeln wir ausführlich in unserem Brotli-RCE-Check.

Lesen Sie diese Liste aufmerksam. Das Projekt bewertet End-of-Life-Linien nicht mehr, weshalb in den Hinweisen ausschließlich unterstützte Versionen aufgeführt werden. Manche dieser Fehler stecken in Code, der in Node.js 20 möglicherweise gar nicht vorhanden ist: Ein Oktober-CVE ist eine Regression, die das Projekt allein auf 26.x und 24.x eingrenzt. Der tatsächliche Status jeder einzelnen CVE für Node.js 20 lautet daher: ungepatcht und unbewertet. Niemand hat Ihnen bestätigt, dass Sie sicher sind – und niemand wird es je überprüfen.

Schwachstellenketten verschärfen die Situation zusätzlich. Der DNS-Fix aus dem Oktober vervollständigt einen Patch aus dem Juni, und ein Fix im Juli baut auf einem weiteren Juni-Patch auf. Jeder spätere Patch setzt somit auf Änderungen auf, die Ihnen fehlen.

„Aber es funktioniert doch noch“

Das tut es. Und genau das ist das Problem.

Eine End-of-Life-Laufzeitumgebung versagt nicht einfach den Dienst. node -v liefert dieselbe Versionsnummer, Ihre Tests laufen fehlerfrei durch und Ihre Dashboards bleiben grün. Das Risiko lauert an Stellen, die Sie nicht überwachen:

• Der Patch selbst dient als Bauplan: Fixes, Sicherheitshinweise und Commits werden zeitgleich öffentlich. Jeder kann somit exakt nachvollziehen, was in einer unterstützten Version geändert wurde, und überprüfen, ob derselbe Code auch in Version 20 steckt.
• Ihre Plattform deployt womöglich munter weiter: AWS Lambda hat nodejs20.x zwar am 30. April 2026 als veraltet markiert, blockiert die Erstellung neuer Funktionen jedoch erst ab dem 29. Juli 2027 und Updates erst ab dem 31. August 2027.
• Packages und Audits ziehen weiter: Das Node.js-Projekt warnt ausdrücklich davor, dass beliebte Pakete EOL-Versionen schrittweise aufgeben und viele Industrie-Audits den Einsatz ungepflegter Runtimes strikt untersagen.

Wählen Sie ein Ziel: Node.js 24 oder 26 – nicht 22

Wechseln Sie noch diese Woche auf 24, wenn Sie den direktesten Weg suchen. Entscheiden Sie sich für 26, wenn Sie bereits jetzt entfernte Features bewältigen können und die maximale Zukunftssicherheit wollen. Überspringen Sie Version 22: Sie erhält zwar den November-Fix, ihr Support endet jedoch bereits am 30. April 2027 – in weniger als sechs Monaten. Sie müssten dieses Migrationsprojekt im Frühjahr also direkt wiederholen.

Die Datumsangaben stammen aus dem offiziellen Node.js-Release-Zeitplan. Prüfen Sie Ihre Zielplattform, bevor Sie sich festlegen. Bei Lambda befindet sich die Node.js-26-Runtime beispielsweise in der Public Preview und wird nicht vom Lambda-SLA abgedeckt – daher ist Version 24 dort aktuell die sicherere Wahl für den Produktivbetrieb.

Schritte zur Migration und Breaking Changes

Alle Angaben in dieser Tabelle stammen aus den offiziellen Release Notes für 22.0.0, 24.0.0, 25.0.0 und 26.0.0 sowie dem Migrationsleitfaden von v22 auf v24. Es handelt sich um eine fokussierte Zusammenfassung für API-Services, nicht um das vollständige Changelog.

Besonders die OpenSSL-Zeile birgt tückische Fallstricke: Ihr eigener Code bleibt unverändert, doch der Handshake mit einem älteren Partner-System schlägt plötzlich zur Laufzeit fehl.

Aktualisieren Sie in einem separaten Branch Ihre .nvmrc, das engines-Feld, Ihr Dockerfile sowie die CI auf die gewünschte Versionslinie (für ein frisch aufgesetztes System hilft der Node.js-Installationsleitfaden). Führen Sie anschließend eine Neuinstallation durch, damit native Module neu kompiliert werden, prüfen Sie Ihren Code auf entfernte APIs, führen Sie die offiziellen Codemods aus und starten Sie den Service mit aktiviertem Deprecation-Tracing:

nvm install 24 && nvm use 24
rm -rf node_modules && npm ci

grep -rnE "assert \{ *type|createCipher\(|createDecipher\(|url\.parse\(|fs\.[FRWX]_OK|SlowBuffer|createSecurePair|_stream_[a-z]+|module\.register\(" \
  --include="*.js" --include="*.mjs" --include="*.ts" --exclude-dir=node_modules .

npx codemod run @nodejs/import-assertions-to-attributes
npx codemod run @nodejs/crypto-createcipheriv-migration
npx codemod run @nodejs/tls-create-secure-pair-to-tls-socket
npx codemod run @nodejs/fs-access-mode-constants

NODE_OPTIONS="--trace-deprecation" npm start

Prüfen Sie die Ausgabe der Codemods manuell. Die Codemod für createCipher weist ausdrücklich darauf hin: Der neu generierte Code kann Daten, die mit der alten API verschlüsselt wurden, nicht entschlüsseln. Planen Sie daher gegebenenfalls eine Datenmigration ein.

Auf der Node.js-Website gibt es bisher keinen eigenen Migrationsleitfaden von 24 auf 26; ziehen Sie für diesen Versionssprung die Release Notes zu 25.0.0 und 26.0.0 heran.

Verifizieren, dass sich die API unter der neuen Version identisch verhält

Unit-Tests können nicht abbilden, wie sich ein neuer TLS-Stack und ein geänderter HTTP-Client unter realem Traffic verhalten. Bei einem Sprung über zwei oder drei Major-Releases empfiehlt sich ein Vorher-Nachher-Vergleich des laufenden Dienstes – eine ideale Aufgabe für Ihren Coding-Agenten.

Mit der Apidog CLI können Claude Code, Codex oder Cursor Ihre Apidog-Testsuiten direkt über das Terminal ausführen. Die einmalige Einrichtung genügt:

npm install -g apidog-cli@latest
apidog login --with-token <YOUR_TOKEN>
npx -y skills add https://apidog.com   # pick your agent when prompted

Geben Sie Ihrem Agenten anschließend folgenden Prompt mit:

My service runs on Node.js 20 in staging. Run Apidog test suite <suiteId> in project
<projectId> against environment <envId> and save reports to reports/node20. When I
redeploy on Node.js 24, run the same suite into reports/node24. List every request
whose status, body, or TLS behavior changed. Then read the service logs for deprecation
warnings and check each failure against the 22, 24, and 25 release notes: removed APIs,
changed defaults, stricter fetch and AbortSignal handling, OpenSSL key size rejections.

Der Agent führt dieselbe Suite vor und nach der Migration aus:

apidog run --test-suite <suiteId> --project <projectId> -e <envId> \
  -r cli,junit --out-dir reports/node20

# redeploy the service on the target line, restart it

apidog run --test-suite <suiteId> --project <projectId> -e <envId> \
  -r cli,junit --out-dir reports/node24

Zwei Aspekte sorgen für verlässliche Vergleichsergebnisse:

• Niemals das Flag -k übergeben: Dieser Parameter deaktiviert die SSL-Validierung und maskiert damit genau jene TLS-Fehler, die Sie aufspüren wollen.
• Binden Sie Upstream-Aufrufe Ihres Services ein: Wird eine Verbindung von OpenSSL verweigert, äußert sich dies als API-Fehler an einem Endpunkt, der vom Altsystem des Partners abhängt. Testen Sie daher gezielt solche Pfade und nicht bloß /health.

Sobald die Migration erfolgreich durchgelaufen ist, sollten Sie die Tests fest in Ihrer Pipeline verankern. Der Apidog-CLI-Leitfaden für CI/CD beschreibt den passenden Workflow, und die Claude-Code-Anleitung zeigt die Konfiguration des Agenten im Detail.

Wenn ein Umstieg diese Woche nicht möglich ist

Gepatchte Builds erwerben: Die End-of-Life-Seite von Node.js nennt drei offizielle Partner im Rahmen des OpenJS Ecosystem Sustainability Programms. HeroDevs bietet mit „Never-Ending Support“ laufende Sicherheits-Patches an. TuxCare portiert mit „Endless Lifecycle Support“ Fixes für End-of-Life-Versionen zurück. NodeSource offeriert Upgrade-Assessments sowie Support. Das Node.js-Projekt stuft dies als vorübergehende Notlösung ein – und genau das ist es auch.

Die Angriffsfläche verkleinern: Folgende Maßnahmen verringern das Risiko gegenüber den oben genannten Schwachstellenklassen, beheben die Ursachen jedoch nicht:

• Terminieren Sie TLS und HTTP/2 an einem gepflegten Proxy oder Load Balancer und kommunizieren Sie mit Node.js innerhalb des privaten Netzwerks ausschließlich über reines HTTP/1.1.
• Verzichten Sie auf das Dekomprimieren von Brotli-Inhalten aus nicht vertrauenswürdigen Quellen – sowohl bei eingehenden Anfragen als auch bei extern abgerufenen Daten.
• Weisen Sie Hostnamen mit NUL-Bytes oder nicht-kanonischen IP-Schreibweisen bereits vor Allowlist-Prüfungen oder ausgehenden Requests ab.
• Isolieren Sie den Dienst: Nutzen Sie Zugangsdaten nach dem Least-Privilege-Prinzip, beschränken Sie den ausgehenden Netzwerkverkehr (Egress) und teilen Sie keine Secrets mit bereits gepatchten Services.

Das Risiko dokumentieren: Benennen Sie Verantwortliche, legen Sie einen verbindlichen Migrationstermin sowie kompensierende Maßnahmen fest – damit „vorübergehend“ auch wirklich ein absehbares Ende hat.

FAQ

Wird Node.js 20 noch unterstützt? Nein. Die Version hat am 30. April 2026 ihr End-of-Life erreicht. Der letzte Build ist 20.20.2 vom 24. März 2026, und das Projekt wird keine weiteren Versionen veröffentlichen.

Ist Node.js 20 für die Sicherheitslücken vom 11. November anfällig? Da noch keine CVE-Details öffentlich sind, lässt sich nicht mit Sicherheit sagen, welche Schwachstellen zutreffen. Der Sicherheitshinweis stellt jedoch klar, dass End-of-Life-Versionen bei einem Sicherheits-Release grundsätzlich betroffen sind – und das Projekt prüft diese nicht mehr einzeln.

Sollte ich stattdessen auf Node.js 22 aktualisieren? Nein. Das wäre zwar der kleinste Versionssprung, allerdings endet der Support für Version 22 bereits am 30. April 2027. Ein Wechsel auf 24 bringt Ihnen ein weiteres Jahr Support, und mit Version 26 gewinnen Sie zwei Jahre.

Node.js 24 oder 26? Wählen Sie 24, wenn Sie noch diese Woche migrieren müssen oder Ihre Plattform Version 26 noch nicht vollständig unterstützt. Nehmen Sie 26, wenn Sie die Möglichkeit haben, jetzt alles gründlich zu testen, da diese Version bis zum 30. April 2029 unterstützt wird.

Ich nutze Node.js 25. Betrifft mich das auch? Ja. Node.js 25 erreichte bereits am 1. Juni 2026 sein End-of-Life; der letzte Build war 25.9.0. Auch dafür gibt es keinen November-Patch, und bis zu Version 26 ist es lediglich ein einzelner Major-Versionssprung.