Node.js 24.18.0 'Krypton' (LTS), 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, die in RFC 9861 definierten Algorithmen TurboSHAKE und KangarooTwelve in Web Cryptography, http.writeInformation für beliebige 1xx-Statuscodes, den Start der V8-Precise-Coverage im JS-Laufzeitsystem sowie JWK-Import/Export für die Post-Quanten-Schlüsselfamilien ML-KEM und SLH-DSA. Am selben Tag liefert Node.js 22.23.1 'Jod' (LTS) 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, 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 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, 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 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 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 (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. 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-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 ist der Hebel für die Stabilisierung.
Die Release liefert zudem eine Multi-PR-Härtung der Web-Cryptography-Stack. PR #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 (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 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 (842 Ergänzungen, 39 Dateien, Filip Skokan) ergänzt JSON-Web-Key-Import/Export für die ML-KEM (vormals Kyber) und SLH-DSA (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 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 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 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 (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, #27921 und #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 (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 (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 (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 (16:44 UTC, @RafaelGSS) einen verwandten Folgefix: PR #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 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 (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, Livia Medeiros), ein alter Fix, der endlich zur Spezifikation passt. SQLite wird auf 3.53.1 (PR #63217) aktualisiert, simdjson auf 4.6.4 (PR #62811) und npm auf 11.16.0 (PR #63602). Die Release enthält zudem PR #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.
