Node.js 22, 24 und 26: Sicherheitsupdates schließen Brotli- und TLS-Lücken
Das Node.js-Projekt hat Sicherheitsupdates für die Linien 22.x, 24.x und 26.x veröffentlicht. Vier der zehn Lücken gelten als hoch, darunter ein Out-of-bounds Write im Brotli-Decoder und zwei Umgehungen der TLS-Hostnamenprüfung. Admins sollten Server, Container-Images und eingebettete Runtimes aktualisieren.
Das Node.js-Projekt hat am Mittwoch, 21. Oktober 2026, Sicherheitsupdates für alle drei unterstützten Release-Linien veröffentlicht: Node.js 22.23.4, 24.22.1 und 26.12.1. Behoben werden zehn Schwachstellen, vier davon stuft das Projekt als hoch ein, darunter ein Out-of-bounds Write im Brotli-Decoder, den das Projekt selbst als Weg zur Remote Code Execution beschreibt. Dazu kommen aktualisierte Abhängigkeiten wie OpenSSL, c-ares, Undici und neue Root-Zertifikate als Reaktion auf die kompromittierte Zwischenzertifizierungsstelle von eMudhra.
Betroffen sind Server, Container, Build-Umgebungen und Werkzeuge, die eine Node.js-Runtime der Linien 22.x, 24.x oder 26.x unterhalb dieser Versionen mitbringen. Nicht betroffen sind reine Browser-Anwendungen ohne Node.js-Server. Hinweise auf aktive Ausnutzung nennt das Projekt nicht. Internetseitig erreichbare Node.js-Dienste sollten trotzdem zeitnah aktualisiert werden, interne Werkzeuge und Entwicklerrechner können ins nächste reguläre Wartungsfenster.
Was ist passiert?
Laut Sicherheitsmitteilung des Projekts betreffen die vier als hoch eingestuften Lücken zentrale Netzwerkfunktionen. CVE-2026-111497 ist ein Out-of-bounds Write im Brotli-Decoder, der Remote Code Execution ermöglichen kann. CVE-2026-105482 beschreibt, dass dns.resolve Namen mit einem NUL-Zeichen abschneidet. Zwei weitere Lücken umgehen die Hostnamenprüfung von TLS-Zertifikaten: CVE-2026-105483 bei IP-Adressen in Vollbreiten-Ziffern (nur 26.x und 24.x) und CVE-2026-106069, wenn sich der Host nur unscharf zu einer IP-Adresse auflösen lässt.
Als mittel eingestuft sind CVE-2026-105481 (ein Keep-alive-Socket verarbeitet eine Antwort, die vor der Anfrage geschrieben wurde), CVE-2026-106072 (DNS-SANs authentifizieren IP-Endpunkte bei nicht kanonischen IPv4-Hostnamen) und CVE-2026-106074. Bei letzterer landen die Entropie-Caches von crypto.randomUUID() und randomInt() in Startup-Snapshots und Single Executable Applications, sodass jeder Prozess dieselben Werte wiederholt. Drei Lücken mit niedriger Einstufung betreffen den ZIP-Support und das Permission Model.
Bei den Abhängigkeiten enthalten alle drei Linien c-ares 1.34.9 und Root-Zertifikate auf Stand NSS 3.131.1. Laut Release-Notes weist TLS zusätzlich Zertifikatsketten mit gesperrten öffentlichen Schlüsseln zurück. Die Linien 22.x und 24.x erhalten OpenSSL 3.5.9, 22.x zusätzlich SQLite 3.53.4. Undici steigt je nach Linie auf 6.29.1, 7.30.1 oder 8.12.2.
Wer ist betroffen?
Laut Mitteilung betreffen die meisten Lücken alle drei Linien 22.x, 24.x und 26.x. Die ZIP-Lücke CVE-2026-106070 und die Permission-Model-Lücke CVE-2026-106071 betreffen nur 26.x. Das Projekt betont außerdem, dass Versionen nach Supportende bei jeder Sicherheitsveröffentlichung grundsätzlich als betroffen gelten. Laut offiziellem Release-Plan endete der Support für Node.js 20 am 30. April 2026, für Node.js 25 am 1. Juni 2026. Dafür gibt es keine Updates mehr.
Relevant ist das nicht nur für klassisch installierte Node.js-Server, sondern auch für Docker-Images auf Basis von node, CI-Runner, statisch gebündelte Single Executable Applications und Desktop-Software mit eingebetteter Runtime wie Electron-Anwendungen. Ob ein Electron-Hersteller die betroffenen Komponenten mitliefert, muss jeweils beim Hersteller geprüft werden.
Wie kritisch ist das?
Das Projekt bewertet die höchste Schwere in jeder Linie als hoch, einen CVSS-Wert nennt die Mitteilung nicht. Am schwersten wiegt die Brotli-Lücke, weil sie laut Projekt Codeausführung ermöglichen kann. Exponiert sind vor allem Anwendungen, die Brotli-komprimierte Daten aus nicht vertrauenswürdigen Quellen dekomprimieren. Die TLS-Lücken erlauben es unter Umständen, Verbindungen mit einem Zertifikat abzusichern, das nicht zum angefragten Ziel passt. Öffentlich erreichbare Dienste gehören deshalb in dieses Patchfenster und nicht erst ins nächste Quartal.
Was sollten Admins jetzt tun?
- Inventar erstellen: Auf Servern, CI-Runnern und in Containern mit
node --versionden Stand prüfen. Sicher sind 22.23.4, 24.22.1 und 26.12.1 oder neuer. - Docker-Images neu bauen: Die offiziellen Tags
node:22,node:24undnode:26wurden laut Docker Hub am 21. Oktober aktualisiert. Basis-Images mitdocker pullneu ziehen, eigene Images mitdocker build --pullneu bauen und die Container neu ausrollen. Gepinnte Tags auf die neuen Versionen anheben. - Installationen über nvm, Paketquellen oder Binärarchive auf die gefixten Versionen anheben und die Dienste neu starten.
- Systeme auf Node.js 20, 25 oder älter auf eine unterstützte Linie migrieren, statt auf Patches zu warten.
- Electron-Anwendungen und andere Software mit eingebetteter Runtime erfassen und Herstellerupdates einplanen.
- Single Executable Applications und Snapshots, die
crypto.randomUUID()nutzen, mit der neuen Version neu erzeugen.
Einordnung für Unternehmen
Node.js steckt oft an Stellen, die nicht als eigener Server im Inventar stehen: in Containern, Build-Prozessen oder Desktop-Werkzeugen. Der eigentliche Aufwand liegt deshalb weniger im Update selbst als im Auffinden aller Runtimes. Ein Neubau der Container reicht nur, wenn das Basis-Image tatsächlich neu gezogen wird, sonst bleibt die alte Version im Cache. Die neuen Root-Zertifikate reagieren auf den eMudhra-Vorfall, der bereits Go und Firefox betraf.
Passende Anleitungen auf S-EDV
- Node.js-Versionen mit nvm auf Ubuntu Server verwalten: Versionswechsel, systemd-Dienste und Cron-Jobs sauber umstellen.
- Docker-Images mit Trivy scannen: Veraltete Node.js-Runtimes in Container-Images aufspüren.
- eMudhra-CA-Schlüssel kompromittiert: Hintergrund zum Zertifikatsvorfall hinter dem ca-cert-Update.
