Datapix

Node.js Sicherheitsupdate Oktober 2026: 10 CVEs, jetzt updaten

Node.js hat am 21.10.2026 Sicherheitsupdates für 26.x, 24.x und 22.x veröffentlicht. Betroffene Versionen, CVEs und Update-Schritte im Überblick.

Akut betroffen? Wir übernehmen Update, Prüfung oder Bereinigung – remote und zum Festpreis.
Node.js Sicherheitsupdate Oktober 2026: Terminal mit Versionsprüfung per node -v

Das Node.js-Projekt hat am 21. Oktober 2026 Sicherheitsupdates für die Release-Linien 26.x, 24.x und 22.x veröffentlicht, die insgesamt zehn Sicherheitslücken (CVEs) schließen, vier davon mit der Schwere „High“. Betroffen sind alle Versionen dieser Linien vor den gefixten Releases sowie grundsätzlich alle End-of-Life-Versionen wie Node.js 20. Du solltest auf Node.js v26.12.1, v24.22.1 oder v22.23.4 updaten.

Kurz gesagt:

  • 10 CVEs, davon 4 mit Schwere „High“ – unter anderem TLS-Hostname-Prüfung, DNS und ein Brotli-Decoder-Fehler, der laut Node.js-Projekt Remote Code Execution ermöglicht.
  • Gefixte Versionen: v26.12.1 (26.x), v24.22.1 (24.x, LTS) und v22.23.4 (22.x, LTS).
  • End-of-Life-Versionen (z. B. Node.js 20 und 25) bekommen keinen Fix – hier hilft nur der Umstieg auf eine unterstützte Linie.

Was steckt im Node.js Security Release vom Oktober 2026?

Die Ankündigung erschien am Mittwoch, 21. Oktober 2026, auf nodejs.org. Das Projekt beziffert die höchste behobene Schwere für jede der drei Release-Linien mit HIGH. Neben den eigenen Schwachstellen in Node.js wurden auch mehrere gebündelte Abhängigkeiten aktualisiert, um öffentlich bekannte Schwachstellen zu schließen.

Für dich als Entscheider heißt das: Jede Node.js-Anwendung in deinem Unternehmen, egal ob API, Webshop-Backend, interne Automatisierung oder Build-Tool, sollte zeitnah auf die neue Version gebracht werden. Für Entwickler heißt das: Laufzeit-Version prüfen, Basis-Images aktualisieren, neu bauen, testen, ausrollen.

Gefixte Versionen im Überblick

Release-Linie Status laut nodejs.org Gefixte Version
26.x Current v26.12.1
24.x LTS („Krypton“) v24.22.1
22.x LTS („Jod“) v22.23.4

Alle drei Releases sind auf den 21.10.2026 datiert und in den Release-Notes ausdrücklich als „security release“ gekennzeichnet.

Die Node.js Sicherheitslücken im Detail

Das Node.js-Projekt nennt pro CVE einen Titel, die Schwere und die betroffenen Release-Linien. Tiefergehende technische Details veröffentlicht es in der Ankündigung nicht. Die folgende Übersicht hält sich deshalb eng an die offiziellen Angaben.

Schwere „High“

CVE Problem (laut Ankündigung) Betroffene Linien
CVE-2026-105482 dns.resolve kürzt Namen, die ein NUL-Zeichen enthalten 26.x, 24.x, 22.x
CVE-2026-105483 Umgehung der TLS-Hostname-Prüfung, wenn die IP in Vollbreiten-Ziffern geschrieben ist 26.x, 24.x
CVE-2026-106069 Umgehung der TLS-Hostname-Prüfung, wenn der Host lose zu einer IP-Adresse aufgelöst wird 26.x, 24.x, 22.x
CVE-2026-111497 Out-of-Bounds-Write im Brotli-Decoder ermöglicht Remote Code Execution 26.x, 24.x, 22.x

Drei der vier schweren Lücken betreffen die Art, wie Node.js Hostnamen und IP-Adressen verarbeitet. Das ist relevant, weil die TLS-Hostname-Prüfung sicherstellt, dass deine Anwendung wirklich mit dem Server spricht, für den das Zertifikat ausgestellt ist. In den Release-Notes heißt der zugehörige Fix „tls: reject non-canonical IP addresses“ – Node.js lehnt also künftig nicht-kanonische IP-Schreibweisen ab.

Die Brotli-Lücke (CVE-2026-111497) ist laut Titel die potenziell folgenreichste, weil sie Remote Code Execution ermöglicht. Brotli ist ein Kompressionsverfahren, das Node.js über das zlib-Modul bereitstellt. Behoben wurde sie durch eine aktualisierte Brotli-Abhängigkeit.

Schwere „Medium“

CVE Problem (laut Ankündigung) Betroffene Linien
CVE-2026-105481 Keep-alive-Socket verarbeitet eine Antwort, die vor dem Senden der Anfrage geschrieben wurde 26.x, 24.x, 22.x
CVE-2026-106072 Fehlerhafte Zertifikatsprüfung bei nicht-kanonischen IPv4-Hostnamen: DNS-SANs können IP-Endpunkte authentifizieren 26.x, 24.x, 22.x
CVE-2026-106074 Entropie-Caches von crypto.randomUUID() und randomInt() landen in Startup-Snapshots und SEAs, sodass jeder Prozess dieselben Werte wiederholt 26.x, 24.x, 22.x

CVE-2026-106074 ist vor allem für Teams interessant, die mit Startup-Snapshots oder Single Executable Applications (SEA) arbeiten. Wenn zufällige IDs oder Zahlen sich über Prozesse hinweg wiederholen, kann das je nach Einsatzzweck (etwa Session- oder Datensatz-IDs) zum Problem werden.

Schwere „Low“

CVE Problem (laut Ankündigung) Betroffene Linien
CVE-2026-106070 ZipFile liefert vom Angreifer kontrollierte Präfix-Bytes nach fehlgeschlagener ZIP-Header-Prüfung 26.x
CVE-2026-106071 Permission Model: zu weitreichende Dateisystem-Freigabe über Wildcard-Radix-Lookup 26.x
CVE-2026-106073 Permission Model: Umgehung über fs.realpathSync 26.x, 24.x, 22.x

Zwei der drei niedrig eingestuften Lücken betreffen das Permission Model von Node.js. Wenn du Node.js-Prozesse damit gezielt auf bestimmte Verzeichnisse beschränkst, solltest du das Update trotz niedriger Einstufung nicht aufschieben.

Aktualisierte Abhängigkeiten

Laut Ankündigung enthält das Release Updates folgender Abhängigkeiten wegen öffentlich bekannter Schwachstellen:

  • c-ares (26.x, 24.x, 22.x) – in den Release-Notes auf Version 1.34.9
  • ca-cert (26.x, 24.x, 22.x) – wegen der Kompromittierung einer Intermediate-CA von eMudhra; die Root-Zertifikate wurden auf NSS 3.131.1 aktualisiert
  • OpenSSL (24.x, 22.x) – auf openssl-3.5.9
  • SQLite (22.x) – auf 3.53.4
  • Undici (26.x, 24.x, 22.x) – in 24.x auf 7.30.1, in 22.x auf 6.29.1

So setzt du das Node.js Sicherheitsupdate um

Ein Update der Laufzeit ist meist unkompliziert, wird in der Praxis aber oft an einer Stelle vergessen: im Docker-Image, auf dem Build-Server oder auf dem einen Altsystem, das „nur intern“ läuft. Gehe deshalb systematisch vor. Kein Admin im Haus oder gerade keine Zeit? Dann übernehmen wir das Update als Notfall-Einsatz zum Festpreis – remote und werktags meist am selben Tag.

1. Version prüfen

Prüfe auf jedem System, auf dem Node.js läuft, die aktive Version:

node -v

Vergleiche die Ausgabe mit der Tabelle oben. Denke dabei an alle Orte, an denen Node.js steckt: Produktionsserver, Container, CI/CD-Runner, Entwickler-Rechner und Serverless-Funktionen.

2. Lokal und auf Servern updaten

Mit nvm installierst du die gefixte Version so (Beispiel 24.x):

nvm install 24.22.1
nvm alias default 24.22.1
node -v

Nutzt du Node.js über den Paketmanager deines Betriebssystems oder ein Paket-Repository, aktualisiere wie gewohnt und kontrolliere anschließend mit node -v, ob die gefixte Version tatsächlich installiert ist. Paketquellen ziehen nicht immer am selben Tag nach.

3. Docker-Images neu bauen

Ein Container behält seine Node.js-Version, bis du ihn neu baust. Pinne die Version im Dockerfile explizit, statt dich auf einen veralteten Cache zu verlassen:

FROM node:24.22.1-alpine

Baue anschließend ohne Cache neu (docker build --pull --no-cache …) und rolle die Container neu aus. Prüfe auch Images, die du von Dienstleistern oder aus Vorlagen übernommen hast.

4. CI/CD-Pipelines anpassen

Pipelines legen die Node.js-Version oft separat fest, etwa über .nvmrc, das Feld engines in der package.json oder eine Versionsangabe im Workflow. Hebe diese Angaben auf die gefixte Version an, damit Builds und Tests nicht mit der verwundbaren Laufzeit laufen.

5. Abhängigkeiten prüfen

Das Laufzeit-Update schließt die Lücken in Node.js selbst und in den gebündelten Bibliotheken. Deine npm-Pakete sind davon unabhängig. Nutze die Gelegenheit für einen kurzen Check:

npm audit
npm outdated

Setzt du Undici als eigenes npm-Paket ein (nicht nur das in Node.js gebündelte fetch), prüfe dessen Version separat.

6. Testen und ausrollen

Die Fixes ändern Verhalten bewusst, zum Beispiel lehnt Node.js laut Release-Notes nun nicht-kanonische IP-Adressen bei TLS ab. Lass deine Tests laufen und achte besonders auf Verbindungen zu internen Diensten, die per IP-Adresse statt per Hostname angesprochen werden.

End-of-Life-Versionen: Warum Node.js 20 jetzt ersetzt werden muss

Das Node.js-Projekt schreibt in jeder Security-Ankündigung, dass End-of-Life-Versionen immer betroffen sind. Laut offiziellem Release-Plan gilt:

  • Node.js 20 („Iron“) hat am 30.04.2026 das End-of-Life erreicht.
  • Node.js 25 hat am 01.06.2026 das End-of-Life erreicht.
  • Node.js 22 ist seit dem 21.10.2025 in der Maintenance-Phase und wird bis zum 30.04.2027 unterstützt.
  • Node.js 24 ist seit dem 20.10.2026 in der Maintenance-Phase und wird bis zum 30.04.2028 unterstützt.
  • Node.js 26 soll laut Plan am 28.10.2026 in die LTS-Phase wechseln.

Für Produktivsysteme in kleinen und mittleren Unternehmen ist eine LTS-Linie meist die richtige Wahl. Läuft bei dir noch Node.js 20 oder älter, ist der Umstieg auf 24.x der nachhaltigere Schritt, da 22.x nur noch bis April 2027 unterstützt wird. Plane dafür Zeit für Tests ein, denn ein Major-Update kann Breaking Changes mitbringen.

Wenn du solche Migrationen nicht selbst stemmen willst, unterstützen wir dich im Bereich Software & Cloud bei der Aktualisierung von Node.js-Anwendungen und Container-Setups.

Updates nicht dem Zufall überlassen

Node.js veröffentlicht Security Releases regelmäßig, der vorherige Termin war Ende Juli 2026. Wer jedes Mal händisch reagiert, verliert Zeit und übersieht leicht ein System. Sinnvoll sind:

  • eine Inventarliste aller Systeme und Container mit Node.js-Version,
  • das Abonnement der Mailingliste nodejs-sec, über die das Projekt Sicherheitsupdates ankündigt,
  • automatisierte Prüfungen in der CI/CD, die veraltete Laufzeiten melden,
  • ein festes Patch-Fenster, in dem Updates getestet und ausgerollt werden.

Genau das übernehmen wir mit Managed IT: laufende Updates, Monitoring und ein Blick auf Systeme, die sonst niemand auf dem Schirm hat. So landet ein Node.js Security Release nicht erst Wochen später in der Produktion.

Was tun, wenn schon etwas passiert ist?

Bemerkst du ungewöhnliches Verhalten, unerwartete Prozesse oder verdächtigen Netzwerkverkehr auf einem System mit verwundbarer Node.js-Version, reicht ein Update allein nicht. Dann gilt: System isolieren, Spuren sichern und den Vorfall professionell aufarbeiten lassen. Über unsere IT-Notfallhilfe erreichst du uns schnell.

Fazit

Das Node.js Sicherheitsupdate vom Oktober 2026 schließt zehn Lücken, vier davon mit hoher Schwere, darunter eine im Brotli-Decoder mit möglicher Remote Code Execution. Aktualisiere auf v26.12.1, v24.22.1 oder v22.23.4, baue Container neu, passe deine Pipelines an und ersetze End-of-Life-Versionen wie Node.js 20. Wenn du dafür dauerhaft Unterstützung möchtest, schau dir unser Managed-IT-Angebot an oder nimm direkt Kontakt mit uns auf.

Quellen

Häufige Fragen

Welche Node.js-Versionen enthalten die Fixes vom Oktober 2026?

Die Fixes stecken in Node.js v26.12.1, v24.22.1 und v22.23.4. Wer eine ältere Version dieser Release-Linien betreibt, sollte auf die jeweilige gefixte Version updaten.

Wie schwer sind die Sicherheitslücken?

Das Node.js-Projekt stuft die höchste Schwere in allen drei Release-Linien als HIGH ein. Insgesamt wurden zehn CVEs veröffentlicht: vier mit hoher, drei mit mittlerer und drei mit niedriger Schwere.

Ist Node.js 20 auch betroffen?

Node.js 20 hat laut offiziellem Release-Plan am 30.04.2026 sein End-of-Life erreicht und bekommt keine Sicherheitsupdates mehr. Das Node.js-Projekt weist darauf hin, dass End-of-Life-Versionen bei Security Releases immer betroffen sind, deshalb solltest du auf 22.x oder 24.x wechseln.

Wie prüfe ich, welche Node.js-Version ich nutze?

Führe auf dem Server, im Container oder in der CI-Umgebung node -v aus. Liegt die Ausgabe unter v22.23.4, v24.22.1 beziehungsweise v26.12.1, ist ein Update nötig.

WeiterlesenAlle Beiträge