Node.js schliesst vierzehn Sicherheitslücken in allen drei LTS-Zweigen

Das Node.js-Projekt hat am Mittwoch, den 11. November 2026, korrigierte Versionen für seine drei aktiv gepflegten Zweige veröffentlicht: 22.x, 24.x und 26.x. Das Paket schließt vierzehn Schwachstellen, sieben davon mit hohem Schweregrad, und betrifft vor allem HTTP/2- und TLS-Server, die nicht vertrauenswürdigen Clients ausgesetzt sind. Ein Speicherleck auf dem Server, das private Schlüssel offenlegt, zählt zu den schwerwiegendsten Fällen.

#Sieben hochkritische Lücken, von einem TLS-Schlüsselleck bis zu einem HTTP/2-Denial-of-Service

Die korrigierten Versionen sind 22.23.5, 24.22.3 und 26.13.1. Die beunruhigendste Lücke, CVE-2026-123864, beruht auf einem Reentranz-Problem in TLSWrap::DoWrite(): Sie kann Server-Speicher, einschließlich privater TLS-Schlüssel, direkt in den Antworttext einer HTTP-Anfrage durchsickern lassen. Unverschlüsselter node:http-Verkehr ist nicht betroffen, nur verschlüsselte Verbindungen sind gefährdet.

Mehrere weitere hochkritische Lücken betreffen den HTTP/2-Stack: ein nicht authentifizierter Verbindungsabbruch durch eine fehlgeschlagene Zusicherung in ~Http2Session(), Sitzungen, die nach einem Protokollfehler beim Herunterfahren nie bereinigt werden, sowie ein Use-after-free beim Abbau eines Streams. Eine weitere, CVE-2026-123872, erlaubt es einem Client, eine TLS-1.2-Sitzung neu auszuhandeln, um den Servernamen zu ändern und die Client-Zertifikatsauthentifizierung zu umgehen.

#Auch mittlere und niedrige Schweregrade verdienen eine Codeprüfung

Das mittlere Paket betrifft unter anderem das Berechtigungsmodell: Platzhalterregeln bei --allow-fs-read und --allow-fs-write gewähren mehr Zugriff als vorgesehen, sodass eine Regel wie /etc/passwd.* am Ende /etc/passwd erlaubt. Ein weiterer Eintrag betrifft https.Agent, wo die Wiederverwendung von TLS-Sitzungen zwischen zwei unterschiedlichen CA-Richtlinien die Zertifikatsprüfung umgeht, dazu kommen Proxy-Zugangsdaten, die im Klartext in einer Fehlermeldung auftauchen, sowie ein rekursiver fs.watch, der unter macOS und Windows eigentlich verborgene Dateinamen offenlegt.

Eine TLS-1.2-Neuaushandlung, die mitten im Handshake den Servernamen wechselt, reicht aus, um eine korrekt konfigurierte Client-Zertifikatsprüfung zu umgehen.

#Jetzt patchen — kein dokumentierter Workaround

Keine der Versionshinweise dokumentiert einen Workaround für ungepatchte Editionen: Das Update bleibt die einzige Abhilfe. Die Versionsprüfung braucht nur eine Zeile, gefolgt von der Installation der korrigierten Version des jeweiligen Zweigs.

node -v
# je nach verwendetem Zweig
nvm install 22.23.5
nvm install 24.22.3
nvm install 26.13.1

Auch die internen Abhängigkeiten llhttp, undici und sqlite wurden in diesem Paket aktualisiert, ohne Änderungen an V8. Bereits ausgelaufene Zweige erhalten keinerlei Korrektur.

#Ein Patch-Rhythmus, der das gesamte Backend-Ökosystem betrifft

Der Versionskalender von Node.js, dessen Umstieg auf einen jährlichen Zyklus Anfang November mit dem Alpha-Zweig 27 bestätigt wurde, ändert nichts an der Behandlung von Sicherheitsnotfällen in den bestehenden LTS-Zweigen. Teams, die solche Updates in Produktion orchestrieren, profitieren von derselben Sorgfalt bei der Transportverschlüsselung in ganz anderen Kontexten, etwa bei der Überwachung der SMTP-Transportverschlüsselung: Ein schlecht geprüftes Zertifikat hat unabhängig vom Protokoll dieselben Folgen.

#Was zu beachten bleibt

Vierzehn in einer einzigen Veröffentlichung behobene Lücken, davon sieben mit hohem Schweregrad und konzentriert auf HTTP/2 und TLS, rechtfertigen ein zügiges Update aller drei LTS-Zweige von Node.js. Teams, die HTTP/2- oder TLS-Server gegenüber externen Clients offenlegen, sollten diesen Patch vorrangig behandeln; alle anderen sollten vor dem nächsten Deployment-Zyklus zumindest ihre Regeln des Berechtigungsmodells überprüfen.

Zum Weiterlesen: Die vollständigen Versionshinweise veröffentlicht das Node.js-Projekt auf nodejs.org.