Node.js schließt 16 CVEs: HTTP/2-Abstürze und ein HTTPS-Bug, der TLS-Schlüssel preisgibt

Am 11. November hat das Node.js-Projekt Sicherheitsreleases für alle drei unterstützten Linien veröffentlicht: 22.23.5 (Jod), 24.22.3 (Krypton) und 26.13.1 (Lithium). Das Paket umfasst 16 CVEs. Sieben davon sind als High eingestuft, sechs als Medium und drei als Low. Nebenbei wurden auch die mitgelieferten Abhängigkeiten llhttp, undici und sqlite aktualisiert.

Die gravierenden Probleme stecken in Nodes eigenem Servercode für HTTP/2, HTTPS und TLS. Ein Bug erlaubt es einem Client ohne Zugangsdaten, einen standardmäßig konfigurierten HTTP/2-Server abzuschießen. Ein anderer lässt einen Client Speicher lesen, der zu anderen Verbindungen gehört, darunter auch private TLS-Schlüssel. Das Projekt meldet keine bekannten Angriffe, und die CISA hat bisher keine der Lücken in ihre KEV-Liste aufgenommen. Einen Workaround nennt das Advisory ebenfalls nicht. Entweder Sie aktualisieren, oder Sie bleiben angreifbar.

Die Bugs, die wir zuerst lesen würden

CVE-2026-123863 (CVSS 8.2, High) ist eine erreichbare Assertion beim Abbau von HTTP/2-Sessions. Der Auslöser ist ziemlich alltäglich: ein Standard-http2-Server, dessen Handler eine Antwort sendet, bevor der Client den Request-Body fertig übertragen hat. Ein Remote-Client kann damit den gesamten Prozess beenden, und zwar über TLS wie auch im Klartext. Es ist eine Variante von CVE-2024-27983, die am damaligen Fix vorbeigerutscht ist. Betroffen sind 24.x ab 24.22.0 und 26.x ab 26.9.0.

CVE-2026-123864 hat mich dazu gebracht, die Kaffeetasse abzustellen. Es ist ein Re-Entrancy-Bug in Nodes HTTPS-Schicht, mit dem ein Angreifer ohne Login Daten aus fremden Verbindungen lesen kann. Das können deren Requests sein oder der private TLS-Schlüssel Ihres Servers. Betroffen sind 22.x, 24.x und 26.x. Der Angreifer braucht eine bestimmte Handler-Struktur: res.flushHeaders() wird aufgerufen, bevor der Request-Body fertig ist, und später folgt res.end() mit einem nicht leeren Chunk. Zusätzlich muss irgendeine Route einen Request-Body zurückgeben oder speichern, denn so gelangen die geleakten Bytes zurück zum Angreifer. Reines node:http ohne TLS ist nicht betroffen.

CVE-2026-123866 ist ein Use-after-free beim Abbau von HTTP/2-Streams. Dabei können freigegebener Speicher oder Antwortdaten einer anderen Verbindung an die Gegenstelle gesendet werden. Alle drei Linien sind betroffen.

CVE-2026-123872 ist unauffälliger, aber unangenehm, wenn Sie mTLS einsetzen. Bei der TLS-1.2-Neuverhandlung kann ein Client den Servernamen ändern und eine bestehende Client-Zertifikat-Authentifizierung auf einen Host übertragen, für den strengere Client-Zertifikat-Regeln gelten. Wenn ein Node-Prozess mehrere Hostnamen mit unterschiedlichen Zertifikatsanforderungen bedient, sollten Sie diesen Punkt zweimal lesen.

Dazu kommt CVE-2026-126051, ein aus der Ferne auslösbarer Absturz des TLS-Servers. Betroffen sind 24.x- und 26.x-Server, die SNICallback, OCSPRequest, newSession, resumeSession oder server.addContext() verwenden.

Linien am Lebensende gehen leer aus. Wenn Sie noch 20.x oder 25.x betreiben, behebt dieses Release für Sie nichts.

Wer hat das alles gefunden? Chris Rohlf hat gemeinsam mit Claude und Anthropic Research 123863, 123864 und mehrere weitere Probleme des Releases gemeldet, und Matteo Collina hat den Großteil der Fixes geschrieben. Ich vermute, dass KI-gestützte Fehlersuche dazu führt, dass wir solche großen Multi-CVE-Pakete eher häufiger sehen werden. Richten Sie Ihren Patch-Prozess darauf aus.

Wer tatsächlich betroffen ist

Gefährdet sind Teams, die HTTP/2 oder HTTPS direkt in Node terminieren. Das ist eine kleinere Gruppe als „alle, die Node betreiben“, aber größer, als die meisten annehmen.

Wenn wir Cloud-native-Apps für Enterprise-Kunden bauen, sitzt Node meist hinter einem Load Balancer oder Reverse Proxy, der TLS übernimmt und per einfachem HTTP/1.1 mit der App spricht. In diesem Setup erreicht Sie der Key-Leak-Bug nicht, weil Klartext-node:http nicht betroffen ist. In unserer Docker-Arbeit begegnet uns aber immer wieder die andere Art von Service: eine Admin-API, ein Webhook-Empfänger, ein kleines internes Tool, bei dem jemand direkt https.createServer oder http2.createSecureServer aufgerufen hat, weil es schneller ging als einen Proxy aufzusetzen. An diese Services denkt beim Upgrade niemand.

Beachten Sie außerdem, dass 123863 auch über unverschlüsseltes HTTP/2 funktioniert. Wenn Ihre Services innerhalb eines Clusters per h2c miteinander sprechen, schützt Sie die vorgelagerte TLS-Terminierung nicht vor dem Absturz.

Auch Mobile-Teams sollten hinschauen. In unseren nativen iOS- und Android-Projekten ist das Backend oft eine Node-API, und wir haben Teams gesehen, die HTTP/2 direkt in Node für den App-Traffic aktiviert haben, um die Latenz zu senken. Lässt sich dieser Prozess aus der Ferne zum Absturz bringen, sehen Ihre Nutzer Ladekreise und fehlgeschlagene Requests, während Ihr Crash-Reporting auf Geräteseite nichts Auffälliges zeigt. Ein verwirrender Incident, den man nachts um zwei debuggen muss.

Aus Security-Sicht machen mir die Speicher-Disclosure-Bugs mehr Sorgen als die Abstürze. Ein Absturz taucht binnen Minuten im Monitoring auf. Ein Leak alarmiert niemanden. Bei unseren Pentests für Gaming-Studios waren die schlimmsten Funde selten die lauten. Es waren die stillen Lesezugriffe, für die niemand eine Logzeile hatte. Und aus unserer DDoS-Arbeit mit Kunden aus dem Reisebereich: Wenn wir Cloudflare oder Akamai vor einen Origin konfigurieren, testen wir als Erstes, ob der Origin noch direkt erreichbar ist. Oft ist er es. Ihre Edge-Konfiguration hilft nicht, wenn ein Angreifer den Node-Prozess ansprechen kann, ohne sie zu passieren.

Was Sie heute tun sollten

1. Erfassen Sie jeden Node-Prozess, nicht nur die Haupt-App. Führen Sie node -v in jedem Container-Image aus, das Sie ausrollen, einschließlich Cronjobs und Sidecars. Ein fixierter Base-Image-Tag aktualisiert sich nicht von selbst, also neu bauen und neu deployen.
2. Aktualisieren Sie je nach Linie auf 22.23.5, 24.22.3 oder 26.13.1. Es gibt keinen Konfigurations-Flag, der das Problem beseitigt.
3. Suchen Sie in Ihrem Code nach dem HTTPS-Leak-Muster: grep -rn "flushHeaders" . Wenn Sie Treffer in einem HTTPS-Handler haben und irgendeine Route Request-Bodys zurückgibt oder speichert, setzen Sie diesen Service an den Anfang der Warteschlange. War er aus dem Internet erreichbar, kostet die Rotation seines TLS-Schlüssels wenig, auch wenn keine Angriffe gemeldet sind.
4. Wenn Sie auf 20.x oder 25.x sind, nehmen Sie die Migration in das Board dieses Sprints auf. Sie auf das nächste Quartal zu verschieben, ist keine Option mehr.
5. Prüfen Sie, dass Ihre Origins nur Traffic von Ihrem CDN oder Load Balancer akzeptieren.

Nichts davon ist glamouröse Arbeit, und ehrlich gesagt ist das Upgrade selbst meist der einfache Teil. Den vergessenen Service zu finden, der sein eigenes TLS terminiert, dauert länger. Wie wir bei solchen Audits vorgehen, zeigen unsere Leistungsübersicht und unsere bisherigen Projekte, und unser Entwicklungsteam erledigt solche Runtime-Upgrades ständig.

Klingt Ihnen ein Node-Service mit eigenem TLS-Setup bekannt, den seit dem Launch niemand mehr angefasst hat? Sprechen Sie uns an.