---
title: "Node.js 24.18.0 'Krypton' LTS Lands Buffer.poolSize at 64 KiB, Web Crypto's TurboSHAKE and KangarooTwelve, and http.writeInformation for Arbitrary 1xx Codes"
description: "Node.js 24.18.0 'Krypton' (LTS), published 2026-06-23, ships the Buffer.poolSize 64 KiB default that landed on Current in 26.3.0, adds RFC 9861's TurboSHAKE and KangarooTwelve to Web Cryptography (PR #62183, 1,521 additions, 13 files), adds http.writeInformation for arbitrary 1xx status codes (PR #63155, 306 additions, 7 files), exposes V8 precise coverage start to the JS inspector runtime (commit 8c989ec4a3), adds JWK import-export for the ML-KEM and SLH-DSA post-quantum key types (PR #62706, 842 additions, 39 files), lands the BoringSSL-side wiring of ML-DSA, ML-KEM, ChaCha20-Poly1305, and AES-KW for Web Crypto (PR #63255), hardens WebCrypto against prototype pollution (PR #63363), aligns crypto.diffieHellman key argument names and accepts key data inputs (PR #62527), reverts the 24.16.0 'noop pause/resume on destroyed streams' behavior (PR #63834), and ships a single-line hotfix on 22.23.1 that backs out an http agent change from the 06-18 security release that triggered an unexpected re-stream."
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), published 2026-06-23 by @richardlau, prepared by @sxa, is the first v24 LTS release of June and the largest of the cycle since 24.0.0. It is the first release on the LTS line to ship the [Buffer.poolSize 64 KiB default from Node.js 26.3.0](/articles/2026-06-03--node-js-26-3-0-buffer-pool-permission-drop) (PR #63597, Matteo Collina), which the original PR measured at +26% on 8 KiB fs.readFileSync workloads and +23% on 16 KiB workloads, and it lands eight SEMVER-MINOR changes spanning crypto, http, inspector, and stream."
  - "The release adds [RFC 9861](https://www.rfc-editor.org/rfc/rfc9861.html)'s TurboSHAKE and KangarooTwelve to Web Cryptography (PR #62183, 1,521 additions, 13 files), aligned with the [WICG webcrypto-modern-algos](https://wicg.github.io/webcrypto-modern-algos/) draft. The implementation is a port of OpenSSL's keccak1600 that ships behind the unstable algorithm flag until OpenSSL supports the primitives natively, at which point they will move to stable `node:crypto`."
  - "Other headline work: `http.writeInformation` exposes a generic HTTP/1 API for arbitrary 1xx status codes on top of the existing HTTP/2 `additionalHeaders` (PR #63155, Tim Perry); WebCrypto gains JWK import-export for the ML-KEM and SLH-DSA post-quantum key types (PR #62706, 842 additions, 39 files); the BoringSSL path now wires ML-DSA, ML-KEM, ChaCha20-Poly1305, and AES-KW (PR #63255); and the v24.16.0 'stream: noop pause/resume on destroyed streams' change is reverted after real-world breakage (PR #63834). The same hotfix pattern ships in 22.23.1 the same day, backing out an http agent change from the 06-18 v22.23.0 security release that re-attached listeners on idle sockets."
faq:
  - question: "What is the headline feature in Node.js 24.18.0 'Krypton'?"
    answer: "There are three headline items, depending on which surface you care about. For runtime performance, the [Buffer.poolSize 64 KiB default](https://github.com/nodejs/node/pull/63597) (Matteo Collina) is the headline: it removes the '4 KiB cliff' in the slab allocator, where the strict inequality `size < (poolSize >>> 1)` skipped a 4 KiB allocation itself, and extends pool coverage to allocations up to 32 KiB. The PR measured +10% to +26% on fs.readFileSync workloads between 4 and 16 KiB. For crypto, [PR #62183](https://github.com/nodejs/node/pull/62183) adds [RFC 9861](https://www.rfc-editor.org/rfc/rfc9861.html)'s TurboSHAKE and KangarooTwelve to Web Cryptography, the first new hash family the runtime has shipped in years. For HTTP, [PR #63155](https://github.com/nodejs/node/pull/63155) adds `response.writeInformation` for arbitrary 1xx status codes, replacing the private `res._writeRaw` workaround that proxy authors had been relying on for years."
  - question: "Why is the Buffer.poolSize change a backport, and what is the performance impact?"
    answer: "The change in PR #63597 first shipped on the Current line in [Node.js 26.3.0](/articles/2026-06-03--node-js-26-3-0-buffer-pool-permission-drop) on 2026-06-01. The default had been 8 KiB since May 2015, predating HTTP/2 frame sizes, modern stream chunk sizes, and the ~10x growth in typical RAM that the PR description cites. The slab allocator's pool check is `size < (Buffer.poolSize >>> 1)`, which means with the 8 KiB default the threshold is 4 KiB and a 4 KiB allocation itself bypasses the pool. The new 64 KiB default extends pool coverage to allocations up to ~32 KiB. The PR's 8-worker benchmark on 4 KiB fs.readFileSync shows +10% throughput, on 8 KiB +26%, on 16 KiB +23%, and 1 MiB files are unaffected. Most production users on the v24 LTS line will see this gain for free when they upgrade."
  - question: "What is TurboSHAKE and KangarooTwelve, and why does Node.js shipping them matter?"
    answer: "TurboSHAKE and KangarooTwelve are extendable-output (XOF) hash functions defined in [RFC 9861](https://www.rfc-editor.org/rfc/rfc9861.html), based on the same Keccak permutation family as SHA-3 and SHAKE. They are faster than SHAKE on long messages and short fixed-length digests, and KangarooTwelve is the IETF's recommended tree-hash mode for high-throughput applications. The browser ecosystem is following the same draft through the [WICG webcrypto-modern-algos](https://wicg.github.io/webcrypto-modern-algos/) proposal. PR #62183 adds both to Node.js's Web Cryptography implementation using OpenSSL's keccak1600 primitives directly; the work is gated behind the unstable algorithm flag until OpenSSL ships native support, at which point it will move to stable `node:crypto`. The change is one of the first times Node.js has shipped a Web Crypto algorithm before the OpenSSL release that backs it."
  - question: "What does http.writeInformation change for proxy and API authors?"
    answer: "Before 24.18.0, HTTP/1 had no public API for sending arbitrary 1xx status codes. The runtime exposed `res.writeContinue` for 100, `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. PR #63155 adds `response.writeInformation({ status, headers })`, a generic HTTP/1 API that 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. The H1 path throws if a final status has already been sent; the H2 path no-ops. 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."
  - question: "What is the post-quantum JWK support in Web Crypto?"
    answer: "PR #62706 (842 additions, 39 files, by Filip Skokan) adds JSON Web Key (JWK) import and export for the [ML-KEM](https://csrc.nist.gov/pubs/fips/203/ipd) (formerly Kyber) and [SLH-DSA](https://csrc.nist.gov/pubs/fips/205/ipd) (formerly Sphincs+) post-quantum key families, both selected by NIST in FIPS 203 and FIPS 205. The JWK shapes follow the [IETF lamps-wg-suites](https://datatracker.ietf.org/wg/lamps/about/) drafts and the JOSE registrations. Combined with the ML-KEM and SLH-DSA primitives that the [Node.js 26 crypto hardening](https://github.com/nodejs/node/pull/63255) (PR #63255) already wired into `node:crypto`, the Web Cryptography side now matches the post-quantum work that 26.x has been carrying for several months. The BoringSSL build path additionally gets ChaCha20-Poly1305, AES-KW, ML-DSA, and ML-KEM wire support in Web Crypto (PR #63255), so a single Node.js binary can now serve both RSA / ECDSA and ML-KEM / ML-DSA / SLH-DSA JWKs in the same Web Crypto namespace."
  - question: "Why was the v24.16.0 'stream: noop pause/resume on destroyed streams' reverted?"
    answer: "PR #63834 (Stewart X Addison) reverts the change that landed in v24.16.0 on 2026-05-21 and made `pause()` and `resume()` no-ops on destroyed streams. 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 revert is committed to v24 LTS the same day, and a related follow-up in [Node.js 22.23.1](https://github.com/nodejs/node/releases/tag/v22.23.1) (also 2026-06-23) backs out the http agent change that was introduced as part of the v22.23.0 security release two weeks ago and was making idle agent sockets re-attach stream listeners. The two reverts are unrelated at the API level but land together because they were both caught in production in the same week."
  - question: "What is the QUIC work in this release?"
    answer: "PR #63267 (James M Snell) lands a multi-commit QUIC improvement patch on top of the libuv work that has been landing in v24 for the past two releases. The visible change is the new `reusePort` option on `QuicEndpoint`, which lets multiple Node.js processes bind to the same UDP port for connection load distribution, and the rate-limiting work on the QUIC version-negotiation and immediate-close code paths. The PR description cites a 10% rps improvement from the packet-handling changes and sets up the libuv PR #5116 reuse-port follow-up that is expected to land in a later 24.x. The change is in the same family as the QUIC work that landed in 24.16.0 and 24.17.0; users running Node.js as a QUIC server in production will see steady incremental gains on the LTS line."
  - question: "What changes in 22.23.1 alongside 24.18.0?"
    answer: "[Node.js 22.23.1 'Jod' (LTS)](https://github.com/nodejs/node/releases/tag/v22.23.1), published the same day at 16:44 UTC by @RafaelGSS, is a two-commit follow-up to the 06-18 v22.23.0 security release. The first commit, [41d2ee13be](https://github.com/nodejs/node/commit/41d2ee13be), switches the v22 windows CI coverage job to `windows-2022` (PR #63940, Richard Lau). The second, [eaa292549e](https://github.com/nodejs/node/commit/eaa292549e), is the same http agent idle-socket fix that ships in 24.18.0 (PR #64004, Matteo Collina): the v22.23.0 security release had added a stream listener to idle agent sockets, which produced an unexpected 'stream listener on idle socket' behavior that surfaced in real production HTTP clients. v22.23.0 users should upgrade to 22.23.1; v24.17.0 users should upgrade to 24.18.0."
  - question: "Are there any breaking changes in Node.js 24.18.0?"
    answer: "Two behavior changes that the release notes flag explicitly. First, the Buffer.poolSize 64 KiB default is a behavior change: applications that benchmark the allocator itself will see different numbers, and a small number of long-running processes that depend on the 4 KiB cliff for memory accounting may see slightly higher steady-state memory. Second, the `stream: noop pause/resume on destroyed streams' revert restores the pre-24.16.0 semantics, which means code that had been updated to work around the 24.16.0 behavior will need to revert its workarounds. The crypto changes are additive: TurboSHAKE, KangarooTwelve, ML-KEM, and SLH-DSA JWK are new algorithms and do not change the behavior of any existing algorithm. Hmac.digest() is added to the documentation-only deprecation list as DEP0206 (PR #63121), which is not a runtime break but signals that the API is being phased out."
  - question: "What is the upgrade path from the previous v24 LTS releases?"
    answer: "Users on v24.17.0 (2026-06-18) should upgrade to v24.18.0; the new features and the stream revert are the reasons. Users on v24.16.0 should upgrade directly to v24.18.0 to pick up the stream revert in one step. Users on v24.0.0 through v24.15.0 should upgrade to v24.18.0 to pick up the entire v24 cycle plus the Buffer pool and crypto work; the v24 line is the current Active LTS, and the [Node.js 24 release schedule](https://github.com/nodejs/release) projects Active LTS maintenance through October 2027. The release also ships an `npm` update to 11.16.0 (PR #63602), a `simdjson` bump to 4.6.4 (PR #62811), a `sqlite` bump to 3.53.1 (PR #63217), and a V8 cherry-pick (commit 6e56f01c4b)."
---

[Node.js 24.18.0 'Krypton' (LTS)](https://github.com/nodejs/node/releases/tag/v24.18.0), 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](https://github.com/nodejs/node/pull/63597) backported from Current, RFC 9861's [TurboSHAKE and KangarooTwelve](https://github.com/nodejs/node/pull/62183) added to Web Cryptography, [http.writeInformation](https://github.com/nodejs/node/pull/63155) for arbitrary 1xx status codes, V8 [precise coverage](https://github.com/nodejs/node/commit/8c989ec4a3) exposed to the JS runtime, and JWK import-export for the [ML-KEM](https://github.com/nodejs/node/pull/62706) and SLH-DSA post-quantum key families. The same day, [Node.js 22.23.1 'Jod' (LTS)](https://github.com/nodejs/node/releases/tag/v22.23.1) 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](https://nodejs.org/en/blog/vulnerability/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](/articles/2026-06-18--node-js-june-2026-security-releases)), 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](https://github.com/nodejs/node/pull/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](https://github.com/nodejs/node/commit/63da0dfd3a4460e117240e84b57af2137469497e), 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](/articles/2026-06-03--node-js-26-3-0-buffer-pool-permission-drop) 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](https://github.com/nodejs/node/pull/62183) (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](https://www.rfc-editor.org/rfc/rfc9861.html). 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](https://wicg.github.io/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](https://redirect.github.com/openssl/openssl/issues/30304) is the tracker that will gate the stabilization.

The release also lands a multi-PR hardening of the Web Cryptography stack. [PR #63363](https://github.com/nodejs/node/pull/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](https://github.com/nodejs/node/pull/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](https://github.com/nodejs/node/pull/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](https://github.com/nodejs/node/pull/62706) (842 additions, 39 files, Filip Skokan) adds JSON Web Key import and export for the [ML-KEM](https://csrc.nist.gov/pubs/fips/203/ipd) (formerly Kyber) and [SLH-DSA](https://csrc.nist.gov/pubs/fips/205/ipd) (formerly Sphincs+) post-quantum key families, both selected by NIST in FIPS 203 and FIPS 205. The JWK shapes follow the [IETF LAMPS WG](https://datatracker.ietf.org/wg/lamps/about/) 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](https://github.com/nodejs/node/pull/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](https://github.com/nodejs/node/pull/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](https://github.com/nodejs/node/pull/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](https://github.com/nodejs/node/issues/22624), [#27921](https://github.com/nodejs/node/issues/27921), and [#7588](https://github.com/nodejs/node/issues/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](https://github.com/nodejs/node/commit/8c989ec4a3) (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](https://github.com/nodejs/node/pull/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](https://github.com/nodejs/node/pull/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](https://github.com/nodejs/node/releases/tag/v22.23.1) (16:44 UTC, @RafaelGSS) ships a related follow-up: [PR #64004](https://github.com/nodejs/node/pull/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](https://github.com/nodejs/release) 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](https://github.com/nodejs/node/pull/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](https://github.com/nodejs/node/pull/63328), Livia Medeiros), a long-standing fix that finally matches the spec. SQLite is updated to 3.53.1 ([PR #63217](https://github.com/nodejs/node/pull/63217)), `simdjson` to 4.6.4 ([PR #62811](https://github.com/nodejs/node/pull/62811)), and `npm` to 11.16.0 ([PR #63602](https://github.com/nodejs/node/pull/63602)). The release also includes [PR #62612](https://github.com/nodejs/node/pull/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.