--- title: "Node.js 24.18.0 'Krypton' LTS bringt Buffer.poolSize auf 64 KiB, TurboSHAKE und KangarooTwelve in Web Crypto sowie http.writeInformation für beliebige 1xx-Codes" description: "Node.js 24.18.0 'Krypton' (LTS), veröffentlicht am 2026-06-23, liefert den aus Node.js 26.3.0 bekannten Buffer.poolSize-Default von 64 KiB auf der LTS-Linie, ergänzt Web Cryptography um die RFC-9861-Algorithmen TurboSHAKE und KangarooTwelve (PR #62183, 1.521 Ergänzungen, 13 Dateien), führt http.writeInformation für beliebige 1xx-Statuscodes ein (PR #63155, 306 Ergänzungen, 7 Dateien), legt den Start der V8-Precise-Coverage in das JS-Laufzeitsystem (Commit 8c989ec4a3), ergänzt JWK-Import/Export für die Post-Quanten-Schlüsseltypen ML-KEM und SLH-DSA (PR #62706, 842 Ergänzungen, 39 Dateien), bindet im BoringSSL-Pfad ML-DSA, ML-KEM, ChaCha20-Poly1305 und AES-KW in Web Crypto ein (PR #63255), härtet WebCrypto gegen Prototype-Pollution (PR #63363), vereinheitlicht die Schlüsselargumentnamen von crypto.diffieHellman und akzeptiert Schlüsseldaten als Eingabe (PR #62527), nimmt das in 24.16.0 eingeführte Verhalten 'stream: noop pause/resume on destroyed streams' zurück (PR #63834) und veröffentlicht am selben Tag den Minimal-Hotfix 22.23.1, der eine in der Sicherheitsrelease v22.23.0 vom 18.06. eingeführte Änderung am HTTP-Agent zurücknimmt, die an inaktiven Agent-Sockets Stream-Listener angehängt hatte." date: 2026-06-24 image: "/images/heroes/2026-06-24--node-js-24-18-krypton-lts-buffer-pool-turboshake.png" author: lschvn tags: ["runtimes", "security", "performance"] tldr: - "Node.js 24.18.0 'Krypton' (LTS), veröffentlicht am 2026-06-23 von @richardlau, vorbereitet von @sxa, ist die erste v24-LTS-Release im Juni und die größte des Zyklus seit 24.0.0. Sie ist die erste Release der LTS-Linie, die den aus [Node.js 26.3.0](/articles/2026-06-03--node-js-26-3-0-buffer-pool-permission-drop) (PR #63597, Matteo Collina) bekannten [Buffer.poolSize-Default von 64 KiB](/articles/2026-06-03--node-js-26-3-0-buffer-pool-permission-drop) bringt, den die Original-PR mit +26 % bei 8-KiB-fs.readFileSync-Workloads und +23 % bei 16 KiB gemessen hatte, und sie liefert acht SEMVER-MINOR-Änderungen quer durch crypto, http, inspector und stream." - "Die Release ergänzt Web Cryptography um [RFC 9861](https://www.rfc-editor.org/rfc/rfc9861.html) TurboSHAKE und KangarooTwelve (PR #62183, 1.521 Ergänzungen, 13 Dateien), im Einklang mit dem [WICG-webcrypto-modern-algos](https://wicg.github.io/webcrypto-modern-algos/)-Entwurf. Die Implementierung ist ein direkter Port der keccak1600-Primitive aus OpenSSL, hinter dem Unstable-Algorithmus-Flag ausgeliefert, bis OpenSSL diese Primitive nativ unterstützt, woraufhin sie in stabiles `node:crypto` wandern." - "Weitere Schwerpunkte: `http.writeInformation` legt eine generische HTTP/1-API für beliebige 1xx-Statuscodes offen, modelliert nach dem bestehenden `additionalHeaders` auf HTTP/2 (PR #63155, Tim Perry); WebCrypto erhält JWK-Import/Export für die Post-Quanten-Schlüsseltypen ML-KEM und SLH-DSA (PR #62706, 842 Ergänzungen, 39 Dateien); der BoringSSL-Pfad bindet nun ML-DSA, ML-KEM, ChaCha20-Poly1305 und AES-KW ein (PR #63255); und die 24.16.0-Änderung 'stream: noop pause/resume on destroyed streams' wird nach Produktionsbrüchen zurückgenommen (PR #63834). Derselbe Hotfix-Stil kommt am gleichen Tag in 22.23.1, die eine in der v22.23.0-Sicherheitsrelease eingeführte HTTP-Agent-Änderung zurücknimmt, die an inaktiven Sockets Stream-Listener angehängt hatte." faq: - question: "Was ist die wichtigste Neuerung in Node.js 24.18.0 'Krypton'?" answer: "Es gibt drei Schwerpunkte, je nachdem, welche Schicht einen betrifft. Für die Laufzeit-Performance ist der [Buffer.poolSize-Default von 64 KiB](https://github.com/nodejs/node/pull/63597) (Matteo Collina) der Aufmacher: Er beseitigt die '4-KiB-Klippe' im Slab-Allokator, wo die strenge Ungleichung `size < (poolSize >>> 1)` dazu führte, dass eine 4-KiB-Allokation den Pool selbst verfehlte, und erweitert die Pool-Abdeckung auf Allokationen bis 32 KiB. Die PR maß +10 % bis +26 % auf fs.readFileSync-Workloads zwischen 4 und 16 KiB. Für Crypto fügt [PR #62183](https://github.com/nodejs/node/pull/62183) [RFC 9861](https://www.rfc-editor.org/rfc/rfc9861.html) TurboSHAKE und KangarooTwelve zu Web Cryptography hinzu, die erste neue Hash-Familie, die das Laufzeitsystem seit Jahren ausliefert. Für HTTP ergänzt [PR #63155](https://github.com/nodejs/node/pull/63155) `response.writeInformation` für beliebige 1xx-Statuscodes als Ersatz für den privaten `res._writeRaw`-Workaround, auf den sich Proxy-Autoren jahrelang verlassen hatten." - question: "Warum ist die Buffer.poolSize-Änderung ein Backport, und wie groß ist die Performance-Wirkung?" answer: "Die Änderung in PR #63597 wurde zuerst auf der Current-Linie in [Node.js 26.3.0](/articles/2026-06-03--node-js-26-3-0-buffer-pool-permission-drop) am 2026-06-01 ausgeliefert. Der Default stand seit Mai 2015 auf 8 KiB, was die HTTP/2-Frame-Größen, moderne Stream-Chunk-Größen und das in der PR-Beschreibung genannte ~10-fache Wachstum des typischen RAMs nicht abdeckte. Die Slab-Allokator-Prüfung lautet `size < (Buffer.poolSize >>> 1)`, sodass mit dem 8-KiB-Default die Schwelle 4 KiB ist und eine 4-KiB-Allokation den Pool selbst verfehlt. Der neue 64-KiB-Default erweitert die Pool-Abdeckung auf Allokationen bis ~32 KiB. Das Benchmark der PR auf 8 Workern zeigt +10 % bei 4 KiB, +26 % bei 8 KiB, +23 % bei 16 KiB, und 1-MiB-Dateien sind unbeeinflusst. Die meisten Produktionsnutzer auf der v24-LTS-Linie erhalten diesen Gewinn beim Upgrade geschenkt." - question: "Was sind TurboSHAKE und KangarooTwelve, und warum ist ihre Auslieferung in Node.js relevant?" answer: "TurboSHAKE und KangarooTwelve sind Extendable-Output-Hashfunktionen (XOF) aus [RFC 9861](https://www.rfc-editor.org/rfc/rfc9861.html), basierend auf derselben Keccak-Permutationsfamilie wie SHA-3 und SHAKE. Sie sind schneller als SHAKE auf langen Nachrichten und auf kurzen Digests fester Länge, und KangarooTwelve ist der von der IETF empfohlene Tree-Hash-Modus für hochlastige Anwendungen; das Browser-Ökosystem folgt demselben Entwurf über die [WICG-webcrypto-modern-algos](https://wicg.github.io/webcrypto-modern-algos/)-Proposal. PR #62183 ergänzt beide in der Web-Cryptography-Implementierung von Node.js direkt auf Basis der keccak1600-Primitive von OpenSSL; die Arbeit ist hinter dem Unstable-Algorithmus-Flag verborgen, bis OpenSSL native Unterstützung liefert, woraufhin die Algorithmen in stabiles `node:crypto` wandern. Es ist eines der ersten Male, dass Node.js einen Web-Crypto-Algorithmus vor der OpenSSL-Release ausliefert, die ihn stützt." - question: "Was ändert http.writeInformation für Proxy- und API-Autoren?" answer: "Vor 24.18.0 gab es auf HTTP/1 keine öffentliche API, beliebige 1xx-Statuscodes zu senden. Das Laufzeitsystem stellte `res.writeContinue` für 100 und `res.writeEarlyHints` für 103 bereit, und damit war Schluss; wer einen individuellen 1xx-Code brauchte oder einen Proxy schrieb, der einen 1xx vom Upstream weiterreichen musste, griff zur privaten Methode `res._writeRaw`, was die PR-Beschreibung explizit als Praxis der eigenen Node.js-Testsuite benennt. PR #63155 ergänzt `response.writeInformation({ status, headers })`, eine generische HTTP/1-API, die die Form von HTTP/2-`additionalHeaders` übernimmt und jeden 1xx-Statuscode außer 101 unterstützt (101 wechselt das Protokoll und bleibt über das `upgrade`-Event behandelt). Die bestehenden `writeContinue` und `writeEarlyHints` sind oberhalb der neuen Methode refaktoriert. Der H1-Pfad wirft, wenn bereits ein finaler Status gesendet wurde; der H2-Pfad no-op't. Proxy-Autoren bekommen eine einzige API, die für die IETF-Codes, individuelle 1xx-Werte und jeden künftig standardisierten 1xx funktioniert, ohne dass pro Status eine eigene Methode nötig wäre." - question: "Was bedeutet die Post-Quanten-JWK-Unterstützung in Web Crypto?" answer: "[PR #62706](https://github.com/nodejs/node/pull/62706) (842 Ergänzungen, 39 Dateien, von Filip Skokan) ergänzt JSON-Web-Key-Import/Export für die [ML-KEM](https://csrc.nist.gov/pubs/fips/203/ipd) (vormals Kyber) und [SLH-DSA](https://csrc.nist.gov/pubs/fips/205/ipd) (vormals Sphincs+) Post-Quanten-Schlüsselfamilien, beide vom NIST in FIPS 203 und FIPS 205 ausgewählt. Die JWK-Formen folgen den Entwürfen der [IETF-LAMPS-Working-Group](https://datatracker.ietf.org/wg/lamps/about/) und den JOSE-Registrierungen. Zusammen mit der BoringSSL-seitigen ML-KEM- und ML-DSA-Anbindung in PR #63255 ist die Web-Cryptography-Seite nun auf dem Stand der Post-Quanten-Arbeit, die die Current-Linie seit dem 26.x-Zyklus mitführt. Ein einzelnes Node.js-Binary kann nun RSA-, ECDSA-, Ed25519-, ML-KEM-, ML-DSA- und SLH-DSA-JWKs im selben Web-Crypto-Namespace bedienen, was für die Produktionsausrollung von Post-Quanten-TLS zählt: Derselbe `crypto.subtle`-Namespace, mit dem ein Server eine RSA-Signatur verifiziert, kann nun eine ML-DSA-Signatur verifizieren, und derselbe `importKey`/`exportKey`-Pfad, der einen P-256-JWK behandelt, kann nun einen ML-KEM-768-JWK behandeln." - question: "Warum wurde das 24.16.0-'stream: noop pause/resume on destroyed streams' zurückgenommen?" answer: "[PR #63834](https://github.com/nodejs/node/pull/63834) (Stewart X Addison) nimmt die am 2026-05-21 in 24.16.0 eingeführte Änderung zurück, die `pause()` und `resume()` auf zerstörten Streams zu No-Ops gemacht hatte. Die Absicht war, das Stream-Cleanup idempotenter zu machen, aber reale HTTP- und Prozess-Spawn-Pipelines verließen sich darauf, dass `pause()` auch nach `destroy()` ein No-Op-und-clean bleibt, und die Änderung erzeugte 'Cannot call method on destroyed stream'-Fehler in zuvor korrekten Codepfaden. Die Zurücknahme wird am selben Tag auf der v24-LTS-Linie committet, und ein verwandter Folgefix in [Node.js 22.23.1](https://github.com/nodejs/node/releases/tag/v22.23.1) (ebenfalls 2026-06-23) nimmt die in der v22.23.0-Sicherheitsrelease eingeführte HTTP-Agent-Änderung zurück, die an inaktiven Agent-Sockets Stream-Listener angehängt und in Produktion ein unerwartetes Re-Stream-Verhalten ausgelöst hatte. Die zwei Zurücknahmen sind auf API-Ebene unabhängig, erscheinen aber zusammen, weil sie in derselben Woche in Produktion entdeckt wurden." - question: "Was enthält die QUIC-Arbeit in dieser Release?" answer: "[PR #63267](https://github.com/nodejs/node/pull/63267) (James M. Snell) liefert ein Multi-Commit-Patch mit QUIC-Verbesserungen auf der libuv-Arbeit auf, die in den letzten beiden Releases auf v24 gelandet ist. Die sichtbare Änderung ist die neue Option `reusePort` an `QuicEndpoint`, mit der mehrere Node.js-Prozesse für Connection-Load-Distribution an denselben UDP-Port binden können, sowie die Rate-Limiting-Arbeit an den QUIC-Version-Negotiation- und Immediate-Close-Codepfaden. Die PR-Beschreibung nennt eine Verbesserung um rund 10 % rps durch die Packet-Handling-Änderungen und bereitet die libuv-Folge-PR #5116 zu reuse-port vor, die in einer späteren 24.x erwartet wird. Die Änderung gehört in dieselbe Familie wie die QUIC-Arbeit, die in 24.16.0 und 24.17.0 landete; wer Node.js in Produktion als QUIC-Server betreibt, sieht auf der LTS-Linie stetige inkrementelle Gewinne." - question: "Was ändert die 22.23.1, die parallel zu 24.18.0 erscheint?" answer: "[Node.js 22.23.1 'Jod' (LTS)](https://github.com/nodejs/node/releases/tag/v22.23.1), am selben Tag um 16:44 UTC von @RafaelGSS veröffentlicht, ist ein Zwei-Commit-Folgefix zur Sicherheitsrelease v22.23.0 vom 18.06. Der erste Commit, [41d2ee13be](https://github.com/nodejs/node/commit/41d2ee13be), stellt den v22-Windows-Coverage-Job auf `windows-2022` um (PR #63940, Richard Lau). Der zweite, [eaa292549e](https://github.com/nodejs/node/commit/eaa292549e), ist derselbe HTTP-Agent-Idle-Socket-Fix, der in 24.18.0 erscheint (PR #64004, Matteo Collina): Die Sicherheitsrelease v22.23.0 hatte an inaktiven Agent-Sockets einen Stream-Listener angehängt, was in Produktion ein unerwartetes 'Stream-Listener an Idle-Socket'-Verhalten auf HTTP-Clients erzeugte. v22.23.0-Nutzer sollten auf 22.23.1 gehen; v24.17.0-Nutzer sollten auf 24.18.0 gehen." - question: "Gibt es Breaking Changes in Node.js 24.18.0?" answer: "Zwei Verhaltensänderungen, die die Release-Notes explizit ausweisen. Erstens ist der Buffer.poolSize-64-KiB-Default eine Verhaltensänderung: Anwendungen, die den Allokator selbst benchmarken, sehen andere Zahlen, und eine kleine Zahl langlebiger Prozesse, die sich auf die 4-KiB-Klippe für ihr Memory-Accounting verlassen, sehen einen leicht höheren Steady-State-Speicher. Zweitens stellt die Zurücknahme von 'stream: noop pause/resume on destroyed streams' die Semantik von vor 24.16.0 wieder her, was heißt, dass Code, der an das 24.16.0-Verhalten angepasst wurde, diese Anpassungen wieder zurücknehmen muss. Die Crypto-Änderungen sind additiv: TurboSHAKE, KangarooTwelve, ML-KEM und SLH-DSA JWK sind neue Algorithmen und ändern das Verhalten keines bestehenden Algorithmus. Hmac.digest() wird in der dokumentierten Deprecation-Liste als DEP0206 ergänzt (PR #63121), was kein Runtime-Bruch ist, aber signalisiert, dass die API ausgemustert wird." - question: "Wie sieht der Upgrade-Pfad von früheren v24-LTS-Releases aus?" answer: "Nutzer auf v24.17.0 (2026-06-18) sollten auf v24.18.0 gehen; die neuen Features und die Stream-Zurücknahme sind die Gründe. Nutzer auf v24.16.0 sollten direkt auf v24.18.0 gehen, um die Stream-Zurücknahme in einem Schritt zu erhalten. Nutzer auf v24.0.0 bis v24.15.0 sollten auf v24.18.0 gehen, um den gesamten v24-Zyklus plus die Buffer-Pool- und Crypto-Arbeit zu erhalten; die v24-Linie ist die aktuelle Active LTS, und der [Node.js-24-Release-Plan](https://github.com/nodejs/release) sieht die Active-LTS-Pflege bis Oktober 2027 vor. Die Release bringt außerdem ein Update von `npm` auf 11.16.0 (PR #63602), einen Bump von `simdjson` auf 4.6.4 (PR #62811), einen Bump von `sqlite` auf 3.53.1 (PR #63217) sowie einen V8-Cherry-Pick (Commit 6e56f01c4b)." --- [Node.js 24.18.0 'Krypton' (LTS)](https://github.com/nodejs/node/releases/tag/v24.18.0), veröffentlicht am 2026-06-23 um 23:11 UTC von @richardlau, vorbereitet von @sxa, ist die größte Release auf der v24-LTS-Linie seit dem Active-Gang der Linie im Oktober 2025. Sie liefert acht SEMVER-MINOR-Änderungen: den aus Current zurückportierten [Buffer.poolSize-Default von 64 KiB](https://github.com/nodejs/node/pull/63597), die in [RFC 9861](https://www.rfc-editor.org/rfc/rfc9861.html) definierten Algorithmen [TurboSHAKE und KangarooTwelve](https://github.com/nodejs/node/pull/62183) in Web Cryptography, [http.writeInformation](https://github.com/nodejs/node/pull/63155) für beliebige 1xx-Statuscodes, den Start der [V8-Precise-Coverage](https://github.com/nodejs/node/commit/8c989ec4a3) im JS-Laufzeitsystem sowie JWK-Import/Export für die Post-Quanten-Schlüsselfamilien [ML-KEM](https://github.com/nodejs/node/pull/62706) und SLH-DSA. Am selben Tag liefert [Node.js 22.23.1 'Jod' (LTS)](https://github.com/nodejs/node/releases/tag/v22.23.1) einen Zwei-Commit-Folgefix zur Sicherheitsrelease v22.23.0 vom 18.06., der eine HTTP-Agent-Änderung zurücknimmt, die in realen HTTP-Clients ein unerwartetes Re-Stream-Verhalten ausgelöst hatte. Die Release landet in derselben Woche auf der LTS-Linie wie die [Node.js-Sicherheitsreleases von Juni 2026](https://nodejs.org/en/blog/vulnerability/june-2026-security-releases/), und das Timing ist bewusst: Die Sicherheitsrelease hat 14 CVEs über v18, v20, v22 und v24 am 2026-06-18 geschlossen (in [unserem vorherigen Artikel zu den Node.js-Sicherheitsreleases](/articles/2026-06-18--node-js-june-2026-security-releases) behandelt), und 24.18.0 ist die nächste Funktionsrelease auf der v24-Linie, die Produktionsnutzer in einem Schritt einspielen können. Der Folge-Hotfix in v22.23.1 ist die zweite Hälfte derselben Woche, denn der Fix in v22.23.0 erzeugte unter realer Last ein unerwartetes Stream-Verhalten, und das Team entschied sich, in v22.23.1 zurückzunehmen statt auf v22.24.0 zu warten. ## Buffer.poolSize-Default verdoppelt sich auf 64 KiB Die wirkungsvollste Laufzeitänderung ist die Anhebung des `Buffer.poolSize`-Defaults von 8 KiB auf 64 KiB, beigetragen von Matteo Collina ([#63597](https://github.com/nodejs/node/pull/63597), 7 Ergänzungen, 2 Dateien). Die Slab-Allokator-Prüfung lautet `size < (Buffer.poolSize >>> 1)`, sodass mit dem 8-KiB-Default die Schwelle 4 KiB ist und die strenge Ungleichung bedeutet, dass eine 4-KiB-Allokation den Pool selbst verfehlt. Der aktuelle Default hilft Allokationen von 1 Byte bis 3999 Byte und bricht abrupt an der seiten-ausgerichteten, HTTP-Frame-großen Grenze ab, an der viele reale Allokationen landen. Die PR-Beschreibung nennt drei Gründe für die Änderung. Die 4-KiB-Klippe ist der erste. Der zweite ist, dass der Default seit [Mai 2015](https://github.com/nodejs/node/commit/63da0dfd3a4460e117240e84b57af2137469497e) auf 8 KiB steht, vor HTTP/2-Frame-Größen (16 KiB bis 1 MiB), modernen Stream-Chunk-Größen und dem ~10-fachen Wachstum des typischen RAMs. Der dritte ist, dass viele `Buffer.allocUnsafe`-Aufrufe im Core (`fs.readFileSync` für Non-UTF-8-Reads, der HTTP-Parser, die Stream-Chunker) im Bereich 4 KiB bis 64 KiB liegen und den Pool verfehlen. Das Benchmark der PR, gefahren auf 8 Worker-Threads in einem Prozess unter Linux 6.8 mit glibc 2.39 auf einem i7-7700, zeigt: | Dateigröße | 8-KiB-Pool (Default) | 64-KiB-Pool | Δ | |---:|---:|---:|:---:| | 512 B | 404k ops/s | 431k ops/s | +7 % | | 2 KiB | 360k ops/s | 367k ops/s | ~ | | 4 KiB | 326k ops/s | 360k ops/s | +10 % | | 8 KiB | 202k ops/s | 254k ops/s | +26 % | | 16 KiB | 148k ops/s | 181k ops/s | +23 % | | 64 KiB | 86k ops/s | 87k ops/s | ~ | | 1 MiB | 8,7k ops/s | 8,6k ops/s | ~ | Der neue 64-KiB-Default erweitert die Pool-Abdeckung auf Allokationen bis ~32 KiB. Die Änderung ist das erste Mal seit 2015, dass der Default sich bewegt. Sie ist nicht breaking, sie betrifft nur den Default, und Anwendungen können `Buffer.poolSize` weiterhin manuell setzen. Dieselbe Änderung wurde bereits auf der Current-Linie in [Node.js 26.3.0](/articles/2026-06-03--node-js-26-3-0-buffer-pool-permission-drop) am 2026-06-01 ausgeliefert; 24.18.0 ist das erste Mal, dass sie auf der LTS-Linie landet. Der Aufmacher jenes früheren Artikels ist für v24-Nutzer nun auch der Aufmacher dieses Artikels. ## Web Cryptography erhält TurboSHAKE und KangarooTwelve Der zweite Aufmacher ist die Aufnahme von [TurboSHAKE und KangarooTwelve](https://github.com/nodejs/node/pull/62183) (PR #62183, 1.521 Ergänzungen, 13 Dateien, Filip Skokan) in die Web-Cryptography-API. Beide sind Extendable-Output-Hashfunktionen aus derselben Keccak-Permutationsfamilie wie SHA-3 und SHAKE, standardisiert in [RFC 9861](https://www.rfc-editor.org/rfc/rfc9861.html). Sie sind schneller als SHAKE auf langen Nachrichten und auf kurzen Digests fester Länge; KangarooTwelve ist der von der IETF empfohlene Tree-Hash-Modus für hochlastige Anwendungen, und das Browser-Ökosystem folgt demselben Entwurf über die [WICG-webcrypto-modern-algos](https://wicg.github.io/webcrypto-modern-algos/)-Proposal. Die Node.js-Implementierung portiert die keccak1600-Primitive aus OpenSSL direkt. Die Arbeit ist hinter dem Unstable-Algorithmus-Flag verborgen, bis OpenSSL native Unterstützung für beide Primitive liefert; dann werden die Algorithmen in stabiles `node:crypto` wandern und der Web-Crypto-Gate wird geöffnet. Die PR ist eines der ersten Male, dass Node.js einen Web-Crypto-Algorithmus vor der OpenSSL-Release ausliefert, die ihn stützt, und der Upstream-Tracker [openssl/openssl#30304](https://redirect.github.com/openssl/openssl/issues/30304) ist der Hebel für die Stabilisierung. Die Release liefert zudem eine Multi-PR-Härtung der Web-Cryptography-Stack. [PR #63363](https://github.com/nodejs/node/pull/63363) (Filip Skokan) härtet WebCrypto gegen Prototype-Pollution, refaktoriert den Async-Pfad in einen neuen internen `CryptoJob`-Modus, reicht `CryptoKey`-Handles direkt an die KDF-Jobs weiter und entfernt das `async`-Schlüsselwort aus den Web-Crypto-Methoden, wo die Arbeit darunter tatsächlich synchron abläuft. [PR #63255](https://github.com/nodejs/node/pull/63255) (Filip Skokan) verkabelt den BoringSSL-Buildpfad so, dass ML-DSA, ML-KEM, ChaCha20-Poly1305 und AES-KW in Web Cryptography verfügbar sind, wenn Node.js gegen BoringSSL gebaut wird. [PR #63111](https://github.com/nodejs/node/pull/63111) zieht die `CryptoKey`-Algorithmus-Slots und die internen `KeyObject`-Slots enger, sodass die beiden Typen nicht versehentlich State teilen können. ## Post-Quanten-JWK-Unterstützung für ML-KEM und SLH-DSA [PR #62706](https://github.com/nodejs/node/pull/62706) (842 Ergänzungen, 39 Dateien, Filip Skokan) ergänzt JSON-Web-Key-Import/Export für die [ML-KEM](https://csrc.nist.gov/pubs/fips/203/ipd) (vormals Kyber) und [SLH-DSA](https://csrc.nist.gov/pubs/fips/205/ipd) (vormals Sphincs+) Post-Quanten-Schlüsselfamilien, beide vom NIST in FIPS 203 und FIPS 205 ausgewählt. Die JWK-Formen folgen den Entwürfen der [IETF-LAMPS-Working-Group](https://datatracker.ietf.org/wg/lamps/about/) und den JOSE-Registrierungen. Zusammen mit der BoringSSL-seitigen ML-KEM- und ML-DSA-Anbindung in PR #63255 ist die Web-Cryptography-Seite von Node.js nun auf dem Stand der Post-Quanten-Arbeit, die die Current-Linie seit dem Beginn des 26.x-Zyklus mitführt. Ein einzelnes Node.js-Binary kann nun RSA-, ECDSA-, Ed25519-, ML-KEM-, ML-DSA- und SLH-DSA-JWKs im selben Web-Crypto-Namespace bedienen, was für die Produktionsausrollung von Post-Quanten-TLS zählt: Derselbe `crypto.subtle`-Namespace, mit dem ein Server eine RSA-Signatur verifiziert, kann nun eine ML-DSA-Signatur verifizieren, und derselbe `importKey`/`exportKey`-Pfad, der einen P-256-JWK behandelt, kann nun einen ML-KEM-768-JWK behandeln. [PR #62905](https://github.com/nodejs/node/pull/62905) ergänzt eine separate Wache gegen doppelte ML-KEM-JWK-`key_ops`, was die Art von Edge-Case ist, die in Interop-Tests mit den Browser-Implementierungen auftaucht. [PR #62626](https://github.com/nodejs/node/pull/62626) ist ein kleinerer Fix, der vor einem `size_t`-Overflow auf der experimentellen 32-Bit-Architektur schützt; die Änderung gehört zur selben Familie wie die 64-Bit-Architektur-Fixes, die in 24.15.0 landeten. ## `http.writeInformation` für beliebige 1xx-Statuscodes [PR #63155](https://github.com/nodejs/node/pull/63155) (306 Ergänzungen, 7 Dateien, Tim Perry) ergänzt `response.writeInformation({ status, headers })`, eine generische HTTP/1-API zum Senden beliebiger 1xx-Statuscodes. Das Laufzeitsystem stellte zuvor `res.writeContinue` für 100 und `res.writeEarlyHints` für 103 bereit, und damit war Schluss; wer einen individuellen 1xx-Code brauchte oder einen Proxy schrieb, der einen 1xx vom Upstream weiterreichen musste, griff zur privaten Methode `res._writeRaw`, was die PR-Beschreibung explizit als Praxis der eigenen Node.js-Testsuite benennt. Die neue Methode übernimmt die Form von `additionalHeaders` auf HTTP/2 und unterstützt jeden 1xx-Statuscode außer 101 (der das Protokoll wechselt und weiterhin über das `upgrade`-Event behandelt wird). Die bestehenden `writeContinue` und `writeEarlyHints` sind oberhalb der neuen Methode refaktoriert. Es gibt eine Inkonsistenz, die die PR unverändert lässt: Der H1-Pfad wirft, wenn bereits ein finaler Status gesendet wurde; der H2-Pfad no-op't. Die PR-Beschreibung markiert diese Inkonsistenz als Kandidaten für eine Angleichung in einem künftigen Major-Bump. Der Fix schließt drei alte Issues, [#22624](https://github.com/nodejs/node/issues/22624), [#27921](https://github.com/nodejs/node/issues/27921) und [#7588](https://github.com/nodejs/node/issues/7588), die im Laufe der Jahre mangels generischer API als Stale geschlossen wurden. Proxy-Autoren bekommen eine einzige API, die für die IETF-Codes, individuelle 1xx-Werte und jeden künftig standardisierten 1xx funktioniert, ohne dass pro Status eine eigene Methode nötig wäre. ## V8-Precise-Coverage für das JS-Laufzeitsystem freigegeben Die [Inspector-Precise-Coverage-Arbeit](https://github.com/nodejs/node/commit/8c989ec4a3) (Commit 8c989ec4a3, sangwook, SEMVER-MINOR) ist nach Zeilenzahl der kleinste Aufmacher der Release und der nützlichste für jeden, der Coverage auf der v24-LTS-Linie fährt. Die Änderung legt das Startsignal der V8-Precise-Coverage über ein neues internes Binding für das JS-Laufzeitsystem offen, sodass sowohl `node:inspector` als auch der Test-Runner die präzise Coverage zur Laufzeit starten können, statt nur beim Bootstrap über `NODE_V8_COVERAGE` oder `--experimental-test-coverage`. Die begleitende [PR #63079](https://github.com/nodejs/node/pull/63079) (sangwook) verkabelt dieselbe Primitive in die `run()`-API des Test-Runners: `run({ coverage: true, isolation: 'none' })` sammelt die Coverage nun korrekt ein, und der Standardausschluss der Test-Dateien wird konsistent zwischen CLI- und API-Pfad angewendet. Die PR behebt einen echten Bug in `test_runner`, bei dem der API-Pfad eine leere Dateiliste meldete, weil das V8-Coverage-Flag nur beim Bootstrap gesetzt wurde. Die Änderung gehört zur selben Precise-Coverage-Arbeit, die in 24.16.0 und 24.17.0 inkrementell ausgeliefert wurde; das 24.18.0-Stück ist die finale Freigabe, die Anwendungscode erlaubt, Coverage on demand zu starten. Für Nutzer, die `c8` oder `nyc` auf der v24-Linie fahren, heißt das, dass der Coverage-Pfad des Test-Runners nun auf LTS first-class ist. ## Die Stream-Zurücknahme und der v22.23.1-Folgefix Die Release nimmt eine Änderung aus 24.16.0 zurück: [PR #63834](https://github.com/nodejs/node/pull/63834) (Stewart X. Addison) dreht die am 2026-05-21 eingeführte Änderung 'stream: noop pause/resume on destroyed streams' zurück. Die Absicht war, das Stream-Cleanup idempotenter zu machen, aber reale HTTP- und Prozess-Spawn-Pipelines verließen sich darauf, dass `pause()` auch nach `destroy()` ein No-Op-und-clean bleibt, und die Änderung erzeugte 'Cannot call method on destroyed stream'-Fehler in zuvor korrekten Codepfaden. Am selben Tag liefert [Node.js 22.23.1](https://github.com/nodejs/node/releases/tag/v22.23.1) (16:44 UTC, @RafaelGSS) einen verwandten Folgefix: [PR #64004](https://github.com/nodejs/node/pull/64004) (Matteo Collina) nimmt die in der v22.23.0-Sicherheitsrelease eingeführte HTTP-Agent-Änderung zurück, die an inaktiven Agent-Sockets einen Stream-Listener angehängt und in Produktion ein unerwartetes Re-Stream-Verhalten auf HTTP-Clients erzeugt hatte. v22.23.0-Nutzer sollten auf 22.23.1 gehen; der Fix landet zur selben Zeit in 24.18.0, also sollten v24.17.0-Nutzer auf 24.18.0 gehen, um sowohl die Stream- als auch die Agent-Zurücknahme zu erhalten. Die zwei Zurücknahmen sind auf API-Ebene unabhängig, erscheinen aber zusammen, weil sie in derselben Woche in Produktion entdeckt wurden. Der [Node.js-22-Release-Plan](https://github.com/nodejs/release) führt die 22.x bis Oktober 2026 in Maintenance LTS, und die Entscheidung des Teams, eine 22.23.1-Wochen-Hotfix herauszugeben statt auf 22.24.0 zu warten, spiegelt wider, dass die LTS-Branches heute als Produktionsziele für langlebige Services dienen. ## Was die 24.18.0 nicht ändert Die Release ändert weder die V8-Hauptversion noch die libuv-Hauptversion noch die öffentliche Addon-API. Die Node-API-Oberfläche nimmt [PR #62710](https://github.com/nodejs/node/pull/62710) (Yilong Li) mit, die `SharedArrayBuffer`-Unterstützung für `napi_create_typedarray` ergänzt, ein kleiner, aber echter Fix für native Module, die `SharedArrayBuffer`-Views an JS freigeben wollen. Die `Date`-Eigenschaften von `fs.Stats` werden aufzählbar ([PR #63328](https://github.com/nodejs/node/pull/63328), Livia Medeiros), ein alter Fix, der endlich zur Spezifikation passt. SQLite wird auf 3.53.1 ([PR #63217](https://github.com/nodejs/node/pull/63217)) aktualisiert, `simdjson` auf 4.6.4 ([PR #62811](https://github.com/nodejs/node/pull/62811)) und `npm` auf 11.16.0 ([PR #63602](https://github.com/nodejs/node/pull/63602)). Die Release enthält zudem [PR #62612](https://github.com/nodejs/node/pull/62612), die Dateien von KI-Assistenten in die `.gitignore` des Repos aufnimmt; eine kleine Meta-Änderung, die für sich genommen ein Signal dafür ist, wo die Node.js-Maintainer die nächste Generation von Contributor-Werkzeugen sehen. Der vollständige Node.js-24-LTS-Release-Plan sieht die Active-LTS-Pflege bis Oktober 2027 und die Maintenance-LTS bis Oktober 2028 vor. 24.18.0 ist die zweite Release im Juni auf der v24-Linie und die erste, die die Buffer-Pool- und Post-Quanten-JWK-Arbeit ausliefert, die sich seit zwei Monaten auf Current angesammelt hatte.