Node.js 24.18.0 'Krypton' (LTS), published 2026-06-23 23:11 UTC by @richardlau and prepared by @sxa, is the largest release on the v24 LTS line since the line went Active in October 2025. It lands eight SEMVER-MINOR changes: the Buffer.poolSize 64 KiB default backported from Current, RFC 9861's TurboSHAKE and KangarooTwelve added to Web Cryptography, http.writeInformation for arbitrary 1xx status codes, V8 precise coverage exposed to the JS runtime, and JWK import-export for the ML-KEM and SLH-DSA post-quantum key families. The same day, Node.js 22.23.1 'Jod' (LTS) ships a two-commit follow-up to the 06-18 v22.23.0 security release, backing out an http agent change that triggered an unexpected re-stream behavior in real production HTTP clients.
The release lands on the LTS line the same week that the Node.js June 2026 security releases shipped, and the timing is intentional: the security release closed 14 CVEs across v18, v20, v22, and v24 on 2026-06-18 (covered in the previous Node.js security release piece), and v24.18.0 is the next feature release on the v24 line that production users can take in one step. The follow-up hotfix in v22.23.1 is the second half of the same week, since the v22.23.0 fix produced unexpected stream behavior in real workloads and the team chose to revert in v22.23.1 rather than wait for v22.24.0.
Buffer.poolSize default doubles to 64 KiB
The most impactful runtime change is the default Buffer.poolSize increase from 8 KiB to 64 KiB, contributed by Matteo Collina (#63597, 7 additions, 2 files). The slab allocator's pool check is size < (Buffer.poolSize >>> 1), so with the 8 KiB default the threshold is 4 KiB and the strict inequality means a 4 KiB allocation itself bypasses the pool. The current default helps allocations from 1 byte to 3999 bytes and abruptly stops at the page-aligned, HTTP-frame-sized boundary where many real allocations land.
The PR description cites three reasons for the change. The 4 KiB cliff is the first. The second is that the default has been 8 KiB since May 2015, predating HTTP/2's 16 KiB to 1 MiB frame sizes, modern stream chunk sizes, and the ~10x growth in typical RAM. The third is that many Buffer.allocUnsafe calls in core (fs.readFileSync for non-utf8 reads, the HTTP parser, the stream chunkers) sit in the 4 KiB to 64 KiB range and miss the pool.
The PR's benchmark, run on 8 worker threads in a single process on Linux 6.8 with glibc 2.39 on an i7-7700, shows:
| File size | 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 | ~ |
The new 64 KiB default extends pool coverage to allocations up to ~32 KiB. The change is the first time the default has moved since 2015. It is not breaking, it only affects the default, and applications can still set Buffer.poolSize manually. The same change already shipped on the Current line in Node.js 26.3.0 on 2026-06-01; v24.18.0 is the first time it lands on the LTS line. The headline of that earlier article is now also the headline of this one for v24 users.
Web Cryptography gains TurboSHAKE and KangarooTwelve
The second headline is the addition of TurboSHAKE and KangarooTwelve (PR #62183, 1,521 additions, 13 files, Filip Skokan) to the Web Cryptography API. Both are extendable-output hash functions from the same Keccak permutation family as SHA-3 and SHAKE, standardized in RFC 9861. They are faster than SHAKE on long messages and short fixed-length digests; KangarooTwelve is the IETF's recommended tree-hash mode for high-throughput applications, and the browser ecosystem is following the same draft through the WICG webcrypto-modern-algos proposal.
The Node.js implementation ports OpenSSL's keccak1600 primitives directly. The work is gated behind the unstable algorithm flag until OpenSSL ships native support for both primitives; at that point, the algorithms will move to stable node:crypto and the Web Crypto gate will be lifted. The PR is one of the first times Node.js has shipped a Web Crypto algorithm before the OpenSSL release that backs it, and the upstream openssl/openssl#30304 is the tracker that will gate the stabilization.
The release also lands a multi-PR hardening of the Web Cryptography stack. PR #63363 (Filip Skokan) hardens WebCrypto against prototype pollution, refactors the async path to a new internal CryptoJob mode, passes CryptoKey handles directly into the KDF jobs, and removes the async keyword from the Web Crypto methods where the work is actually synchronous underneath. PR #63255 (Filip Skokan) wires the BoringSSL build path so that ML-DSA, ML-KEM, ChaCha20-Poly1305, and AES-KW are available in Web Cryptography when Node.js is built against BoringSSL. PR #63111 tightens the CryptoKey algorithm slots and KeyObject internal slots so that the two types cannot accidentally share state.
Post-quantum JWK support for ML-KEM and SLH-DSA
PR #62706 (842 additions, 39 files, Filip Skokan) adds JSON Web Key import and export for the ML-KEM (formerly Kyber) and SLH-DSA (formerly Sphincs+) post-quantum key families, both selected by NIST in FIPS 203 and FIPS 205. The JWK shapes follow the IETF LAMPS WG drafts and the JOSE registrations.
Combined with the BoringSSL-side ML-KEM and ML-DSA wiring in PR #63255, the Web Cryptography side of Node.js now matches the post-quantum work that the Current line has been carrying since the 26.x cycle began. A single Node.js binary can now serve RSA, ECDSA, Ed25519, ML-KEM, ML-DSA, and SLH-DSA JWKs in the same Web Crypto namespace, which matters for the production rollout of post-quantum TLS: the same crypto.subtle namespace that a server uses to verify an RSA signature can now verify an ML-DSA signature, and the same importKey / exportKey path that handles a P-256 JWK can now handle an ML-KEM-768 JWK.
PR #62905 adds a separate guard against duplicate ML-KEM JWK key_ops, which is the kind of edge case that surfaces in interop tests with the browser implementations. PR #62626 is a smaller fix that guards against a size_t overflow on the experimental 32-bit architecture; the change is in the same family as the 64-bit-architecture fixes that landed in v24.15.0.
http.writeInformation for arbitrary 1xx status codes
PR #63155 (306 additions, 7 files, Tim Perry) adds response.writeInformation({ status, headers }), a generic HTTP/1 API for sending arbitrary 1xx status codes. The runtime previously exposed res.writeContinue for 100 and res.writeEarlyHints for 103 and that was it; anyone who needed a custom 1xx or who was writing a proxy that needed to forward a 1xx from the upstream had to use the private res._writeRaw method, which the PR description calls out as something the Node.js test suite itself had been doing.
The new method mirrors the existing HTTP/2 additionalHeaders shape and supports any 1xx status code except 101, which switches protocols and is still handled by the upgrade event. The existing writeContinue and writeEarlyHints are refactored on top of the new method. There is one inconsistency the PR keeps as-is: the H1 path throws if a final status has already been sent, while the H2 path no-ops. The PR description flags this as a candidate for alignment in a future major bump.
The fix closes three long-standing issues, #22624, #27921, and #7588, which had been closed as stale over the years because no general API existed. Proxy authors get a single API that works for the IETF-defined codes, custom 1xx values, and any future standardized 1xx without a per-status method.
V8 precise coverage exposed to the JS runtime
The inspector precise coverage work (commit 8c989ec4a3, sangwook, SEMVER-MINOR) is the smallest headline in the release by line count and the most useful one for anyone running coverage on the v24 LTS line. The change exposes V8's precise coverage start signal to the JS runtime through a new internal binding, so node:inspector and the test runner can both start precise coverage at runtime rather than only at bootstrap via NODE_V8_COVERAGE or --experimental-test-coverage.
The companion PR #63079 (sangwook) wires the same primitive into the test runner's run() API: run({ coverage: true, isolation: 'none' }) now correctly collects coverage, and the test-file exclusion default is applied consistently between the CLI and the API path. The PR fixes a real bug in test_runner where the API path was reporting an empty file list because the V8 coverage flag was only set at bootstrap.
The change is the same precise coverage work that has been shipping incrementally in 24.16.0 and 24.17.0; the 24.18.0 piece is the final exposure that lets application code start coverage on demand. For users running c8 or nyc against the v24 line, this means the test runner's coverage path is now first-class on LTS.
The stream revert and the v22.23.1 follow-up
The release reverts one change from 24.16.0: PR #63834 (Stewart X Addison) backs out the 'stream: noop pause/resume on destroyed streams' change that landed on 2026-05-21. The intent was to make stream cleanup more idempotent, but real-world HTTP and process-spawn pipelines relied on pause() being a no-op-then-clean even after destroy, and the change produced 'Cannot call method on destroyed stream' failures in code paths that were correct before the change.
The same day, Node.js 22.23.1 (16:44 UTC, @RafaelGSS) ships a related follow-up: PR #64004 (Matteo Collina) backs out the v22.23.0 security release's change to the http agent, which had been adding a stream listener to idle agent sockets and producing an unexpected re-stream behavior in production HTTP clients. v22.23.0 users should upgrade to 22.23.1; the fix lands in v24.18.0 at the same time, so v24.17.0 users should upgrade to 24.18.0 to pick up both the stream revert and the agent revert.
The two reverts are unrelated at the API level but land together because they were both caught in production in the same week. The Node.js 22 release schedule has 22.x in Maintenance LTS through October 2026, and the team's choice to issue a 22.23.1 one-week hotfix rather than wait for 22.24.0 reflects how the LTS branches are now used as production targets for long-running services.
What 24.18.0 does not change
The release does not change the v8 major version, the libuv major version, or the public addon API. The Node-API surface picks up PR #62710 (Yilong Li), which adds SharedArrayBuffer support to napi_create_typedarray, a small but real fix for native modules that want to expose SharedArrayBuffer views to JS. The fs.Stats Date properties become enumerable (PR #63328, Livia Medeiros), a long-standing fix that finally matches the spec. SQLite is updated to 3.53.1 (PR #63217), simdjson to 4.6.4 (PR #62811), and npm to 11.16.0 (PR #63602). The release also includes PR #62612, which adds AI assistants' files to the repo's .gitignore; a small meta change that is itself a signal of where the Node.js maintainers think the next generation of contributor tooling is going.
The full Node.js 24 LTS release schedule projects Active LTS maintenance through October 2027 and Maintenance LTS through October 2028. v24.18.0 is the second release of June on the v24 line and the first to ship the Buffer pool and post-quantum JWK work that has been accumulating on Current for two months.
