Das Node.js-Projekt hat am 18. Juni 2026 ein koordiniertes Sicherheitsrelease ausgeliefert, das auf einen Schlag jede aktive Release-Linie abdeckt: v22.23.0 für die „Jod"-LTS, v24.17.0 für die „Krypton"-LTS und v26.3.1 für die Current-Linie. Zwölf CVEs landen in dem Drop, zwei davon mit High-Bewertung, der Rest verteilt sich auf Medium und Low. Das Release ist auf jeder Linie ein Security-Release, wobei v26.3.1 zusätzlich die kleine Reihe von Feature-Patches mitnimmt, die auf v26.3.0 folgen (der Buffer-Pool-64-KiB-Default, die neue httpValidation-Option und die permission.drop-API), aber noch nicht unter dem vorherigen Embargo standen.
Der vorherige Node.js-Security-Drop dieser Form fand im März 2026 statt (siehe unsere Berichterstattung). Das Muster ist dasselbe: Embargo-Fixes sammeln sich an, das Embargo fällt, und das Projekt liefert den kompletten Satz am selben Tag über alle drei Linien aus. Was diesmal anders ist, ist das Cluster aus TLS- und Crypto-CVEs, das die High- und Medium-Bänder dominiert. Vier der sechs Medium-Einträge sind TLS-förmig, und einer der zwei Highs ist ein WebCrypto-Output-Längen-Guard, der die crypto.subtle-API betrifft, von der inzwischen viel Serverless- und Edge-Code abhängt.
Die zwei High-Severity-Fixes
CVE-2026-48618, TLS-Hostname-Normalisierung für Server-Identity-Checks. Matteo Collinas Patch zielt auf den Pfad, in dem ein Node.js-TLS-Server den vom Client gelieferten Hostnamen gegen das präsentierte Zertifikat prüft. Vor dem Fix hat der Vergleichspfad die verglichenen Hostnames nicht konsistent normalisiert, was einem sorgfältig konstruierten Host (typischerweise mit gemischter Groß-/Kleinschreibung, Trailing-Dots, IDN-Encoding oder einer Mischung aus URL-encodierten und rohen Zeichen) erlaubte, die Prüfung zu umgehen und sich an einen Virtual Host zu binden, den der Client gar nicht erreichen wollte. Der Patch normalisiert den Hostnamen einheitlich auf der SNI-Seite, der Zertifikat-SAN-Seite und der URL-Seite der ursprünglichen Client-Anfrage, was Node mit X509_VERIFY_PARAM_set1_host aus OpenSSL 3.x und mit dem WHATWG-URL-Parser in Einklang bringt. Für alle, die TLS im Node-Prozess terminieren statt an einem Load Balancer, ist das der Headline-Fix des Releases.
CVE-2026-48933, WebCrypto-Cipher-Output-Längen-Guard. Filip Skokans Fix landet in den SubtleCrypto.encrypt- und SubtleCrypto.decrypt-Pfaden. Bestimmte Algorithmen (vor allem AES-CTR und AES-CBC, wenn der Aufrufer einen Counter- oder Tag-getrimmten Output anfordert) akzeptieren einen length-Parameter, den der vorherige Codepfad nicht immer gegen den tatsächlich vom darunterliegenden OpenSSL-Aufruf produzierten Buffer durchgesetzt hat. Ein bösartiger oder fehlerhafter Aufrufer konnte eine length über die Cipher-Ausgabe hinaus übergeben und entweder über den vorgesehenen Buffer hinaus lesen oder, je nach Algorithmus, Bytes beobachten, die eigentlich hätten getrimmt werden sollen. Der Patch clampet den zurückgegebenen Output auf die angeforderte Länge und validiert die Eingabelänge auf der Encrypt-Seite, was die Read-Past-End- und Write-Past-End-Fälle schließt. Diese Art von Fix ist relevant für Code, der Nodes crypto.subtle für HMAC-basierte Authentifizierung, für Passkey-Flows und für jede Library nutzt, die Envelope-Encryption in der browserförmigen SubtleCrypto-API macht.
Die sechs Medium-Fixes
Das Medium-Band ist das Fleisch des Releases. Sechs CVEs, die sich alle in einen Denial-of-Service oder in eine informationspreisgabe mit niedrigem Aufwand verwandeln lassen, und die alle auf dem normalen Patch-Zeitplan liegen sollten, statt auf ein „nur High"-Triage zu warten.
- CVE-2026-48615, Proxy-Credentials in Tunnel-Fehlern. Wenn ein Node.js-HTTP-Client die
CONNECT-Methode nutzt, um einen Tunnel durch einen HTTPS-Proxy zu öffnen, hat der alte Fehlerpfad die Proxy-URL (inklusive der eingebetteten Credentials) in die geworfene Fehlermeldung emittiert. Der Patch redaktiert den Credential-Teil, bevor der Fehler sichtbar wird, sodass ein Stacktrace oder eine Logdatei das Proxy-Passwort nicht mehr leakt. Der Fix sitzt inlibundtest, was bedeutet, dass er sowohl den Runtime-Pfad als auch die Test-Fixtures berührt, die die Fehlerform prüfen. - CVE-2026-48619, http2-
originSet-Memory-Wachstum. Der HTTP/2-Server-Pfad hat Origin-Einträge in ein internesoriginSetohne hartes Limit aufgenommen, was eine einzige Verbindung das Set unbegrenzt wachsen ließ. Der Patch setzt eine vernünftige Obergrenze, ab der neue Einträge abgelehnt werden. Bei HTTP/2 im Speziellen kann eine einzige TCP-Verbindung viele Requests bedienen, daher ist eine unbegrenzte pro-Verbindung-Datenstruktur de facto unbegrenzt pro Angreifer. - CVE-2026-48928, TLS-case-sensitives SNI-Context-Matching. Die SNI-basierte Context-Auswahl (
servername-Event,SNICallback) hat bisher einen case-sensitiven Vergleich gemacht. RFC 6066 schreibt case-insensitives SNI-Matching auf dem Wire-Format vor, aber Nodes interne Context-Auswahl war strenger als das Wire-Format verlangte, was eine Klasse von Bugs produzierte, in denen „derselbe Hostname je nach Schreibweise zu unterschiedlichen Zertifikaten routet". Der Fix senkt den Vergleich auf case-insensitive, was konsistent mit dem Wire-Format und mit dem ist, was OpenSSL selbst tut. - CVE-2026-48930, NUL-Bytes in DNS-Hostnames. Ein Hostname, der ein eingebettetes NUL-Byte (
\x00) enthielt, wurde bisher von den Modulendnsundnetakzeptiert, was ein seit Langem bekannter Injection-Vektor ist, weil das C-getaddrinfound Verwandte das NUL als String-Terminator behandeln. Der Patch weist solche Hostnames an der Grenze ab, was das klassische Angriffsmuster „schneide-den-String-am-NUL" schließt, das in irgendeiner Form in der Netzwerkschicht jeder Sprache schon einmal aufgeschlagen ist. - CVE-2026-48934, TLS-Session-Reuse an Host gebunden. Der TLS-Session-Cache hat bisher zugelassen, dass eine aus einer früheren Verbindung zu einem Host fortgesetzte Session für einen anderen Host wiederverwendet wird. Der Fix bindet das Session-Ticket an den Hostnamen, den die ursprüngliche Verbindung authentifiziert hat, sodass ein Client eine Session nicht über Hosts hinweg verschieben kann (was ein Session-Fixation-Vektor in Code wäre, der sich auf Session-Resumption als Authentifizierungskontext verlässt).
- CVE-2026-48937, nghttp2-1.69.0-Integration. Das ist das Dependency-Follow-up. Die v22- und v24-Linien springen mit nghttp2 auf 1.69.0, was in der Node-Commit-Message als SEMVER-MAJOR getaggt ist, weil Upstream Breaking Changes in der Integration ausgeliefert hat. Tim Perrys Follow-up absorbiert diese im Node-Wrapper. Die v26-Linie behält vorerst ihre 26.2.0-Basis-nghttp2.
Die vier Low-Fixes
Das Low-Band ist Permission-Model-Hardening, mit einer HTTP-Ausnahme.
- CVE-2026-48617,
process.chdiraufwritereport. Ein Pfad, in demprocess.chdirnicht gegen die Read/Write-Allow-Lists des Permission-Modells geprüft wurde. - CVE-2026-48931, http-Response-Queue-Poisoning in
http.Agent. Eine Low-Severity-Klasse, in der die Antwort-Queue des Agents von einem bösartigen Server vergiftet werden konnte, was in einem engen Race-Fenster zu einem Use-after-Free führte. Matteo Collinas Fix zieht den Queue-Lebenszyklus enger. - CVE-2026-48935,
FileHandle.utimesmit Permission-Modell.FileHandle.utimesist jetzt deaktiviert, wenn das Permission-Modell aktiv ist, weil der zugrundeliegendeutimes-Syscall nicht auf der Allow-List stand und als Seitenkanal zum Auslesen des Filesystems missbraucht werden konnte. - CVE-2026-48936, pipe-open- und chmod-net-Scope (nur v26). Die v26-Linie bekommt zusätzlich eine engere Permission-Behandlung um
pipe(2)undchmod(2), also die zwei Syscalls, die das Permission-Modell in einem halb-eingeschränkten Zustand belassen hatte.
Dependency-Updates und die LTS-/Current-Aufteilung
Drei Dependency-Updates landen auf jeder Linie, eines ist nur LTS.
- OpenSSL 3.5.7 auf v22, v24 und v26. Routinemäßiges Security-Refresh; die OpenSSL-3.5.x-Linie ist die, auf der Node ist, seit v24 LTS wurde.
- llhttp 9.4.2 auf allen Linien. Das HTTP-Parser-Refresh ist eine Minor-Version, keine Public-API-Änderung.
- undici geht auf 8.5.0 auf v26, 7.28.0 auf v24 und 6.27.0 auf v22. Die Versionsaufteilung spiegelt die Node-Policy wider, pro Release-Linie ein anderes Major von
undicizu pinnen, sodass der mitgelieferte Fetch-Client dem Major folgt, gegen das die Linie ursprünglich ausgeliefert wurde. - nghttp2 1.69.0 auf v22 und v24 nur. Die v26-Linie behält ihre 26.2.0-Basis.
Was zu tun ist
Wenn Sie auf v22 LTS sind, aktualisieren Sie auf v22.23.0. Wenn Sie auf v24 LTS sind, aktualisieren Sie auf v24.17.0. Wenn Sie auf v26 Current sind, aktualisieren Sie auf v26.3.1. Das Release ist auf jeder Linie ein Security-Release, also ist das Update auf dem normalen Patch-Zeitplan die richtige Bewegung und nichts, was man aufschiebt. Wer noch auf v20 sitzt, ist aus der aktiven LTS raus und sollte den Wechsel auf v22 planen (oder, falls die eigene Toolchain es trägt, v24).
Für die Highs bei TLS und WebCrypto ist der praktische Impact auf Code, der TLS im Node-Prozess terminiert (statt an einem Load Balancer), und auf Code, der crypto.subtle direkt nutzt (statt durch eine höherliegende Library wie jose zu gehen). Die Library-Wrapper sanitisieren das length-Argument in der Regel, bevor sie die darunterliegende API aufrufen, also ist der WebCrypto-Fix vor allem für Code relevant, der direkt mit SubtleCrypto spricht. Der TLS-Hostname-Fix betrifft jeden Server, der das servername-Event oder SNICallback nutzt, um ein Zertifikat per Hostname auszuwählen.
Das ist das zweite Node.js-Sicherheitsrelease 2026, und das Muster ist mittlerweile vertraut: Embargo-Fixes sammeln sich zwischen den aktiven Linien an, das Projekt liefert den kompletten Satz am selben Tag aus, und die LTS- und Current-Releases bewegen sich zusammen. Die TLS-lastige Form dieses Drops erinnert daran, dass die TLS- und Crypto-Oberflächen von Node nach wie vor die volumenstärkste CVE-Kategorie sind, und dass die Gewohnheit des Projekts, sie in einem einzigen koordinierten Release zu bündeln, das ist, was die Update-Story für die Leute einfach hält, die Node in Produktion betreiben.