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.
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
- Node.js: Wednesday, October 21, 2026 Security Releases
- Node.js 26.12.1 (Current) – Release-Notes
- Node.js 24.22.1 (LTS) – Release-Notes
- Node.js 22.23.4 (LTS) – Release-Notes
- Node.js Release Schedule (GitHub)
- Node.js Security Policy
- Mailingliste nodejs-sec
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.


