Für den Absturz über CVE-2026-123863 genügt ein HTTP/2-Server in Standardkonfiguration, der antwortet, bevor der Request-Body vollständig angekommen ist – ein Verhalten, das das Node.js-Projekt als typisch bezeichnet. Der Angriff funktioniert sowohl über TLS als auch über unverschlüsselte Verbindungen.
Das Speicherleck CVE-2026-123866 betrifft alle drei Linien. Ab den Versionen 24.22.0 und 26.9.0 kann ein Client es allein auslösen. Auf 22.x sowie älteren Builds von 24.x und 26.x tritt es weiterhin auf, wenn der Server selbst einen Stream mitten in einer Antwort schließt, etwa nach einem Leerlauf-Timeout.
Eine gesonderte Lücke in HTTPS-Servern, CVE-2026-123864, kann einem nicht authentifizierten Client erlauben, Speicher anderer Verbindungen auszulesen, „einschließlich privater TLS-Schlüssel und Anfragen anderer Nutzer“, so das Projekt. Betroffen sind alle drei Linien. Voraussetzung ist ein Handler, der res.flushHeaders() aufruft, bevor der Request-Body vollständig eingetroffen ist, und später res.end() mit Daten aufruft. Um den abgeflossenen Speicher lesen zu können, braucht es zudem eine Route, die einen Request-Body zurücksendet oder speichert. Reine HTTP-Server auf Basis von node:http sind nicht betroffen.
Die übrigen vier hoch eingestuften Schwachstellen:
- CVE-2026-123865: Ein Client kann jeden HTTP/2-Server in Standardkonfiguration dazu bringen, Speicher und Dateideskriptoren dauerhaft zu belegen; alle drei Linien.
- CVE-2026-123874: Auf 24.x und 26.x kann ein Client den Serverspeicher beschädigen, wenn der Server Dateien mit stream.respondWithFile() oder stream.respondWithFD() ausliefert. Auf allen drei Linien kann zudem das Abbrechen solcher Downloads den Server abstürzen lassen (CVE-2026-123875, mittlere Einstufung).
- CVE-2026-126051: Ein Client kann einen TLS-Server auf 24.x und 26.x zum Absturz bringen, wenn dieser die Hooks SNICallback, OCSPRequest, newSession oder resumeSession oder server.addContext() verwendet.
- CVE-2026-123872: Auf einem TLS-Server mit strengeren Client-Zertifikatsregeln für bestimmte Hostnamen kann ein für einen anderen Hostnamen zugelassener Client bei einer TLS-1.2-Neuverhandlung zu einem strengeren Hostnamen wechseln, ohne dessen Regeln zu erfüllen; alle drei Linien.
Diese acht Lücken stecken im eigenen HTTP/2-, HTTPS- und TLS-Servercode von Node.js und sind daher dort relevant, wo ein Node.js-Prozess solche Verbindungen selbst annimmt.
Als einzige Abhilfe nennt der Sicherheitshinweis das Update auf die korrigierte Version der jeweiligen Linie; einen Workaround für Server, die noch nicht aktualisiert werden können, gibt es nicht. Linien am Ende ihres Lebenszyklus, darunter 20.x und 25.x, erhalten keine Korrektur und sind nach Angaben des Projekts grundsätzlich betroffen.
Angriffe über die Lücken meldet das Projekt nicht. Offen bleibt auch, ob Betreiber von Servern, die die Bedingungen für die HTTPS-Lücke erfüllten, nach dem Update TLS-Schlüssel oder andere Geheimnisse austauschen sollten. Fünf der Schwachstellen, darunter CVE-2026-123863 und CVE-2026-123864, meldete Chris Rohlf in Zusammenarbeit mit Claude und Anthropic Research.
