Node.js-Sicherheitsupdate (Oktober 2026)
Am 21. Oktober 2026 hat Node.js ein Sicherheitsrelease mit 10 CVEs für die Linien 26.x, 24.x und 22.x veröffentlicht. Die schwerste, CVE-2026-111497, ist ein Out-of-bounds-Write im Brotli-Dekompressor, der Remotecodeausführung erlaubt. Die korrigierten Versionen sind v26.12.1, v24.22.1 und v22.23.4; 20.x und 25.x sind am Lebensende und bekommen keinen Patch.
Haben Sie diese Schwachstelle? Wir aktualisieren Node.js auf Ihren Servern, in Docker-Images und Pipelines, prüfen, ob die Anwendung wie vorher antwortet, und planen den Linienwechsel, wenn Sie noch auf 20.x oder 25.x sind.
$ node -vv22.20.0# 22.x ist in v22.23.4 behoben: betroffen$ docker run --rm api:prod node -vv20.19.5# Das Produktions-Image läuft auf 20.x: kein Patch$ cat .nvmrc22# Das Repo legt die Linie fest, nicht den Patchv26.12.1 · v24.22.1 · v22.23.4Zehn CVEs in einem Release, vier davon hoch
Das Release behebt vier Schwachstellen mit hoher, drei mit mittlerer und drei mit niedriger Schwere. Stand 21. Oktober war für keine davon eine Ausnutzung gemeldet.
CVE-2026-111497 ist ein Out-of-bounds-Write im Brotli-Dekompressor, der Remotecodeausführung erlaubt. Man muss zlib nicht selbst aufrufen, um angreifbar zu sein: Laut Cyberkendra dekomprimieren Express 5 und fetch() Brotli automatisch.
Die anderen drei hohen betreffen das Netzwerk. CVE-2026-106069 und CVE-2026-105483 umgehen die Hostname-Prüfung bei TLS-Zertifikaten, also die Prüfung, die sicherstellt, dass Ihre Anwendung bei einer HTTPS-Anfrage mit dem richtigen Server spricht. CVE-2026-105482 lässt dns.resolve Namen abschneiden, die ein NUL-Zeichen enthalten.
Dasselbe Release lehnt Zertifikatsketten ab, die die kompromittierten Schlüssel von eMudhra verwenden, der indischen Zertifizierungsstelle, deren acht Zwischenzertifikate mit schwachen Schlüsseln erzeugt wurden. Die Linien 20.x und 25.x am Lebensende bekommen davon nichts.
Korrigierte Node.js-Versionen
Läuft ein Dienst mit einer älteren Version als der seiner Linie, ist er betroffen. Für 20.x und 25.x gibt es keine korrigierte Version: Es bleibt nur der Linienwechsel.
| Linie | Behoben in | Hinweis |
|---|---|---|
| 26.x | v26.12.1 | |
| 24.x | v24.22.1 | |
| 22.x | v22.23.4 | |
| 25.x | Kein Patch | Lebensende: auf 26.x wechseln |
| 20.x | Kein Patch | Lebensende: auf 22.x oder 24.x wechseln |
Prüfen Sie das
- Sie betreiben APIs, Backends oder Server-Side-Rendering (Next.js, Nuxt, Astro, NestJS, Express) mit Node.js.
-
node -vauf dem Server oder im Docker-Image zeigt eine ältere Version als die Ihrer Linie. - Ihr Dockerfile nutzt ein Tag wie
node:22und das Image wurde nicht neu gebaut: Es enthält noch die Version vom Build-Zeitpunkt. - Ein Dienst läuft noch auf 20.x oder 25.x: Für diese Linien kommt kein Patch.
- Ihre Anwendung dekomprimiert Brotli (über
fetch(), Express 5 oder einen eigenen Proxy) oder stellt HTTPS-Anfragen an Dritte.
Wenn Sie noch auf 20.x oder 25.x sind
Node.js hat für dieses Release keine vorübergehenden Gegenmaßnahmen veröffentlicht. Auf einer Linie ohne Support behebt nur der Wechsel die Lücken.
- 01 Linien am Lebensende bekommen weder diese noch künftige Korrekturen.
- 02 Der Wechsel von 20.x auf 22.x oder 24.x erfordert meist eine Prüfung der Abhängigkeiten mit nativen Modulen und einen Test des kompletten Builds.
- 03 Während der Migration sollten Sie wissen, welche Endpunkte komprimierte Bodies annehmen und welche Dienste externe Inhalte laden: Diese ziehen zuerst um.
Sieben Schritte, in dieser Reihenfolge
Wir wenden auf jedem Server dasselbe Verfahren an: zuerst klären, welche Version wo läuft, dann korrigieren und zum Schluss prüfen, ob vor dem Patch jemand eingedrungen ist.
Versionsinventar
Wir finden heraus, wo Node.js läuft: Server, Docker-Images, Serverless-Funktionen, CI-Runner und die .nvmrc oder das engines-Feld jedes Repositorys. Überall kann eine andere Version stecken.
Sofortmaßnahme
Ohne offizielle Gegenmaßnahme beginnen wir bei den am stärksten exponierten Diensten: Wer Brotli-Bodies annimmt oder Inhalte Dritter lädt, kommt zuerst dran.
Update
Wir wechseln auf v26.12.1, v24.22.1 oder v22.23.4, bauen die Images neu und legen die Version in Dockerfile, .nvmrc und CI fest. Sind Sie auf 20.x oder 25.x, planen wir den Linienwechsel.
Prüfung
Wir prüfen die Version im Container, der in Produktion läuft, führen die Tests aus und kontrollieren, dass HTTPS-Aufrufe an Dritte weiterhin Zertifikate validieren.
Suche nach Kompromittierungsindikatoren
Wir durchsuchen Anwendungs- und System-Logs nach Prozessabstürzen, unerklärten Neustarts und Prozessen oder Dateien, die dort nicht hingehören.
Rotation von Secrets, falls nötig
Gibt es Hinweise auf einen Zugriff, rotieren wir die sensiblen Umgebungsvariablen: API-Keys, Datenbank-Zugangsdaten und Tokens.
Beobachtung neuer Advisories
Wir halten die Version jedes Dienstes und das Lebensende seiner Linie fest, damit das nächste Sicherheitsrelease bei diesem Inventar ansetzt.
Wo Node.js ungepatcht bleibt
Dienste auf Node 20 und unklar, was der Umzug kostet?
Kostenlose Beratung →Häufige Fragen zum Node.js-Sicherheitsrelease
Welche Node.js-Versionen beheben CVE-2026-111497?
Ich nutze Node 20. Bin ich betroffen?
Betrifft mich das, wenn ich Brotli nicht nutze?
Reicht es, das Docker-Basis-Image zu wechseln?
Sagen Sie uns, wo Ihr Node.js läuft
Wir beginnen mit dem Inventar: welche Version jeder Dienst nutzt, welcher zuerst aktualisiert wird und welche Linie eine Migration braucht.
Erzählen Sie uns Ihre Herausforderung. Wir schlagen die Lösung vor.
Unverbindlich. Innerhalb von 24 Stunden erhalten Sie ein Angebot mit Umfang, Zeitplan und Budget. Ohne Kleingedrucktes.