Node.js: HTTP/2- und HTTPS-Schwachstellen lassen Clients Server abstürzen und Daten anderer Nutzer lesen

Was ist passiert?

Am 11. November 2026 hat das Node.js-Projekt Sicherheitsversionen für seine drei unterstützten Release-Linien veröffentlicht. Die korrigierten Versionen sind 22.23.5, 24.22.3 und 26.13.1. Sie beheben 16 Schwachstellen in Node.js selbst, sieben davon sind als hoch eingestuft. Die Releases aktualisieren außerdem die mitgelieferten Abhängigkeiten llhttp (22.x, 24.x, 26.x), undici (24.x, 26.x) und sqlite (22.x, 24.x).

Die wichtigsten Probleme betreffen den Servercode, den Node.js selbst für HTTP/2, HTTPS und TLS bereitstellt:

• HTTP/2-Serverabsturz (24.x und 26.x): Jeder nicht authentifizierte Client kann den Node.js-Prozess zum Anhalten bringen. Der Server benötigt dafür nur die Standard-HTTP/2-Konfiguration und einen Handler, der antwortet, bevor der Request-Body vollständig eingetroffen ist. Das Projekt bezeichnet dieses Verhalten als typisch. Der Angriff funktioniert über TLS und über unverschlüsselte Verbindungen.
• HTTP/2-Speicheroffenlegung (alle drei Linien): Ein Server kann einem Client Teile seines Speichers senden, einschließlich Antworten, die für andere Verbindungen bestimmt sind. Ab 24.22.0 und 26.9.0 kann ein Client dies selbst auslösen. Bei 22.x sowie älteren 24.x- und 26.x-Builds kann es passieren, wenn der Server einen Stream mitten in einer Antwort schließt, beispielsweise nach einem Idle-Timeout.
• HTTPS-Speicheroffenlegung (alle drei Linien): Ein nicht authentifizierter Client kann laut Projekt Speicher anderer Verbindungen lesen, „einschließlich TLS-Private-Keys und Anfragen anderer Nutzer“. Voraussetzung ist ein Handler, der res.flushHeaders() aufruft, bevor der Request-Body beendet ist, und später res.end() mit Daten aufruft. Um den abgeflossenen Speicher zu lesen, benötigt der Angreifer zusätzlich eine Route, die einen Request-Body zurücksendet oder speichert.
• HTTP/2-Ressourcenerschöpfung (alle drei Linien): Ein Client kann erreichen, dass jeder Standard-HTTP/2-Server dauerhaft Speicher und Dateideskriptoren belegt.
• HTTP/2-Dateiauslieferung (24.x und 26.x): Ein Client kann den Serverspeicher beschädigen, wenn der Server Dateien mit stream.respondWithFile() oder stream.respondWithFD() ausliefert. Auf allen drei Linien kann das Abbrechen solcher Downloads außerdem den Server zum Absturz bringen (als mittel eingestuft).
• TLS-Serverabsturz (24.x und 26.x): Ein Client kann einen TLS-Server zum Absturz bringen, der die Hooks SNICallback, OCSPRequest, newSession oder resumeSession oder server.addContext() verwendet.
• Umgehung der TLS-Client-Zertifikatsprüfung (alle drei Linien): Manche Server wenden für bestimmte Hostnamen strengere Regeln für Client-Zertifikate an. Auf diesen Servern kann ein Client, der für einen anderen Hostnamen freigegeben ist, während einer TLS-1.2-Renegotiation auf einen strengeren wechseln, ohne dessen Regeln zu erfüllen.

Laut Advisory gibt es keine Angriffe, die diese Schwachstellen ausnutzen.

Wer ist betroffen?

• Server mit Node.js 22.x vor 22.23.5, 24.x vor 24.22.3 oder 26.x vor 26.13.1.
• Nicht mehr unterstützte Linien, einschließlich 20.x und 25.x, erhalten mit diesem Release keinen Fix. Laut Projekt sind solche Versionen grundsätzlich betroffen.
• Die schwerwiegenden serverseitigen Probleme betreffen nur Fälle, in denen ein Node.js-Prozess selbst HTTP/2-, HTTPS- oder TLS-Verbindungen annimmt. Beispiele sind die integrierten Module node:http2, node:https oder node:tls oder Frameworks, die diese zur TLS- oder HTTP/2-Terminierung verwenden.
• Reine HTTP-Server mit node:http sind von der HTTPS-Speicheroffenlegung nicht betroffen.
• Der HTTP/2-Absturz betrifft nur die Linien 24.x und 26.x, nicht 22.x.

Sie sind deutlich weniger gefährdet, wenn ein Reverse Proxy wie nginx, Apache, HAProxy oder ein Load Balancer TLS und HTTP/2 terminiert und Node.js von diesem nur unverschlüsseltes HTTP/1.1 erhält. Sie sollten trotzdem aktualisieren, da das Release weitere Korrekturen und Abhängigkeitsupdates enthält.

Was Sie jetzt tun sollten

1. Alle Node.js-Installationen finden. Denken Sie an Systempakete, Versionsmanager (nvm, n, Volta), Docker-Images, CI-Runner und Hosting-Panels, die eigenes Node.js mitbringen.
2. Auf die korrigierte Version Ihrer Linie aktualisieren: 22.23.5, 24.22.3 oder 26.13.1. Wenn Sie Distributions- oder Herstellerpakete nutzen (zum Beispiel NodeSource oder die Paketquellen Ihrer Linux-Distribution), installieren Sie das Update, sobald Ihre Paketquelle diese Versionen bereitstellt.
3. Nicht mehr unterstützte Versionen ablösen. Wenn Sie noch 20.x, 25.x oder ältere Versionen betreiben, migrieren Sie auf eine unterstützte Linie. Das Advisory nennt keine Workarounds für Server, die sich nicht aktualisieren lassen.
4. Container-Images neu bauen mit einem aktualisierten Node.js-Basisimage und neu deployen. Das Aktualisieren des Hosts allein ändert das Node.js in Containern nicht.
5. Alle Node.js-Prozesse neu starten (systemd-Units, PM2, Docker-Container usw.), damit die neue Laufzeitumgebung geladen wird. Prüfen Sie danach, ob Ihre Anwendungen normal antworten.
6. Erwägen Sie, Geheimnisse zu rotieren, falls Sie betroffen waren. Das Advisory sagt nicht, ob Server, die die Bedingungen für die HTTPS-Speicheroffenlegung erfüllten, TLS-Schlüssel oder andere Geheimnisse ersetzen sollten. Wenn einer Ihrer Node.js-HTTPS-Server diese Bedingungen erfüllte und aus dem Internet erreichbar war, sollten Sie Ihr TLS-Zertifikat und den Schlüssel erneuern.

So prüfen Sie, ob Sie betroffen sind

• Führen Sie node -v auf jedem Server und in jedem Container aus (docker exec <container> node -v). Versionen unter 22.23.5, 24.22.3 oder 26.13.1 in ihrer Linie sowie jede nicht mehr unterstützte Linie wie 20.x oder 25.x sind betroffen.
• Mit PM2 zeigen pm2 list und pm2 show <app>, welches Node.js-Binary und welche Version jede Anwendung nutzt.
• Prüfen Sie, ob Ihre Anwendungen TLS oder HTTP/2 selbst in Node.js terminieren: Suchen Sie im Code nach http2.createSecureServer, http2.createServer, https.createServer, tls.createServer, respondWithFile, respondWithFD, SNICallback und addContext.
• Prüfen Sie Process-Manager und Systemprotokolle auf unerwartete Neustarts oder Abstürze von Node.js. Wiederholte Abbrüche eines HTTP/2-Servers können auf Versuche hinweisen, den Absturz auszulösen.

Quellen

• https://thehackernews.com/2026/11/nodejs-fixes-16-flaws-including-http2.html