--- title: "Node.js 26.4.0 'Current' Ships node:vfs Subsystem (Matteo Collina), ESM Loader Package Maps (Maël Nison), TLS Certificate Compression, TCP_KEEPINTVL/TCP_KEEPCNT, and argon2 Stable" description: "Node.js 26.4.0 (Current), published 2026-06-24 by @aduh95, lands eight SEMVER-MINOR changes: a minimal node:vfs subsystem that mounts user-supplied virtual filesystems (PR #63115, Matteo Collina) plus a follow-up that dispatches node:fs/promises to mounted VFS instances (PR #63537), package maps for ESM loaders that route bare specifiers through the loader hooks (PR #62239, Maël Nison), TLS certificateCompression that wires RFC 8879 zlib and zstd compression through the OpenSSL build config (PR #62217, Tim Perry), TCP_KEEPINTVL and TCP_KEEPCNT support in net.Socket.setKeepAlive (PR #63825, Guy Bedford), caller-supplied buffers in fs.readFile / fs.readFileSync (PR #63634, Matteo Collina), closeIdleConnections that now also drops pre-request sockets (PR #63470, semimikoh), net.BlockList advanced to Release Candidate stability (PR #63050), and crypto argon2 + KEM encap/decap marked stable (PR #63924, Filip Skokan). The release also adds WebCrypto cSHAKE (PR #63988), QUIC listEndpoints (PR #63536) and X509Certificate handles (PR #63191), dgram connectSync / bindSync (PRs #63838 + #63932, Guy Bedford), early-TCP net.BoundSocket (PR #63951), an experimental fast FFI call path for AArch64 and x86_64 (PRs #63068 + #63941, Paolo Insogna), npm 11.17.0 (PR #63857), sqlite 3.53.2, and libffi 3.6.0." date: 2026-06-25 image: "/images/heroes/2026-06-25--node-js-26-4-current-vfs-loader-package-maps.png" author: lschvn tags: ["runtimes", "tooling", "security"] tldr: - "Node.js 26.4.0 'Current', published 2026-06-24 by @aduh95, is the first release on the 26.x line to add a minimal `node:vfs` subsystem ([PR #63115](https://github.com/nodejs/node/pull/63115), Matteo Collina) and to dispatch `node:fs/promises` to user-mounted VFS instances ([PR #63537](https://github.com/nodejs/node/pull/63537)). The two VFS PRs land the same week as the [Node.js 24.18.0 'Krypton' LTS release](/articles/2026-06-24--node-js-24-18-krypton-lts-buffer-pool-turboshake), which means the sandboxing primitives that the Current line carries are now also a step away from the LTS line that production users actually deploy." - "The other headline SEMVER-MINOR work is [PR #62239](https://github.com/nodejs/node/pull/62239) (Maël Nison, the Yarn creator), which implements package maps for ESM loader hooks. Loader authors can now read the same `imports` map that Node.js already uses to resolve bare specifiers in the application graph, and the change is the first time the ESM loader hooks expose the package map machinery as a first-class API. The release also adds TLS certificateCompression on top of the OpenSSL compression work ([PR #62217](https://github.com/nodejs/node/pull/62217), Tim Perry), and exposes TCP_KEEPINTVL and TCP_KEEPCNT in `net.Socket.setKeepAlive` ([PR #63825](https://github.com/nodejs/node/pull/63825), Guy Bedford)." - "Other concrete changes: `crypto.argon2` and `crypto.encap` / `crypto.decap` are marked stable ([PR #63924](https://github.com/nodejs/node/pull/63924), Filip Skokan); WebCrypto gains cSHAKE and non-byte digest lengths ([PR #63988](https://github.com/nodejs/node/pull/63988)); `net.BlockList` advances to Release Candidate ([PR #63050](https://github.com/nodejs/node/pull/63050)); QUIC exposes a `listEndpoints` API and returns X509Certificate handles instead of raw OpenSSL handles ([PR #63536](https://github.com/nodejs/node/pull/63536), [PR #63191](https://github.com/nodejs/node/pull/63191)); `dgram` gets synchronous `connectSync` / `bindSync` ([PRs #63838](https://github.com/nodejs/node/pull/63838) + [#63932](https://github.com/nodejs/node/pull/63932), Guy Bedford); an experimental fast FFI call path lands for AArch64 and x86_64 ([PRs #63068](https://github.com/nodejs/node/pull/63068) + [#63941](https://github.com/nodejs/node/pull/63941), Paolo Insogna); npm ships 11.17.0, sqlite 3.53.2, libffi 3.6.0, and the [Node.js 25 line is marked End-of-Life in the docs](https://github.com/nodejs/node/pull/63692)." faq: - question: "What is the headline feature in Node.js 26.4.0 'Current'?" answer: "There are two headline items, depending on which surface you care about. For runtime architecture, the new [node:vfs subsystem](https://github.com/nodejs/node/pull/63115) (Matteo Collina) is the headline: a minimal VFS layer that lets application code mount virtual filesystems, plus a follow-up ([PR #63537](https://github.com/nodejs/node/pull/63537)) that dispatches `node:fs/promises` calls to the mounted VFS instances instead of going to the real disk. This is the foundation that future sandboxed-file APIs in Node.js will sit on. For the ESM loader ecosystem, [PR #62239](https://github.com/nodejs/node/pull/62239) (Maël Nison, the Yarn creator) implements package maps for ESM loader hooks, the first time loader hooks get a first-class API for reading the same `imports` map that the host runtime uses to resolve bare specifiers. Tooling authors (Vite, Rolldown, esbuild, swc, oxc) and framework authors who build their own loaders get a uniform path through the loader hooks for the first time." - question: "What does the node:vfs subsystem do, and why does it matter?" answer: "The new `node:vfs` subsystem is a minimal virtual filesystem layer that application code can mount and unmount at runtime. [PR #63115](https://github.com/nodejs/node/pull/63115) adds the subsystem itself: a small in-process registry of mounted VFS instances, plus the public `node:vfs` module that exposes `mount`, `unmount`, `getMount`, and `getMounts`. [PR #63537](https://github.com/nodejs/node/pull/63537) wires the layer into `node:fs/promises`, so a `readFile` call on a path that begins with a mounted prefix is dispatched to the VFS instance instead of the OS. The piece is the runtime-side foundation for sandboxed execution: build tools can hand a loader a virtual filesystem that contains the project tree, serverless platforms can hand a request handler a virtual filesystem that contains only the request scope, and IDE language servers can hand a debugger probe a virtual filesystem that contains the file being debugged. The VFS instance interface is intentionally minimal in this first cut; richer semantics (symlinks, file watching, real-path resolution) are expected to land in follow-up Current releases." - question: "How do package maps for ESM loader hooks work?" answer: "[PR #62239](https://github.com/nodejs/node/pull/62239) (Maël Nison) implements package maps for the ESM loader hooks. The runtime already has a `package.json`-style `imports` map that lets the application graph resolve bare specifiers (`#internal/api`, `lodash/sortBy`); loader hooks previously had to re-implement the map lookup themselves because the resolution was internal to the module loader. The new API exposes the same resolution as a first-class call on the loader hooks, so a loader that needs to know whether a specifier resolves to a remapped path (or to a subpath) can read the result directly without walking the package.json itself. For build tool authors, this is the missing piece for implementing Node.js-compatible import maps on top of a bundler; the import-map spec already defines the wire format, and Node.js is now exposing the same shape that browser import maps consume. The PR description frames it as the loader hooks side of the same import-map work that [Vite 8.1 's chunkImportMap](/articles/2026-06-24--vite-8-1-stable-bundled-dev-mode) ships at the build-output layer." - question: "What is TLS certificate compression, and when does it help?" answer: "TLS certificate compression is the [RFC 8879](https://www.rfc-editor.org/rfc/rfc8879) extension that lets the TLS handshake send the server certificate chain in a compressed form. It is most useful when the chain includes a large post-quantum signature, which is the same reason Chrome and Firefox have been rolling it out over the past year. [PR #62217](https://github.com/nodejs/node/pull/62217) (Tim Perry) adds a `certificateCompression` option on `tls.createSecureContext` and `https.Server` that accepts an array of compression algorithms (`'zlib'` and `'zstd'`), and updates the OpenSSL build config so that the OpenSSL compression primitives are linked into the Node.js binary. The companion [PR #63255](https://github.com/nodejs/node/pull/63255) that already shipped in 24.18.0 wired ML-DSA, ML-KEM, ChaCha20-Poly1305, and AES-KW for BoringSSL builds, but the compression work in 26.4.0 is the first time the OpenSSL build path exposes the same surface. Servers that enable it on a chain that includes a post-quantum signature should see a noticeably shorter TLS handshake." - question: "Why does exposing TCP_KEEPINTVL and TCP_KEEPCNT matter?" answer: "[PR #63825](https://github.com/nodejs/node/pull/63825) (Guy Bedford) adds `TCP_KEEPINTVL` and `TCP_KEEPCNT` to the options accepted by `net.Socket.setKeepAlive(enable, initialDelay)`. Before 26.4.0, `setKeepAlive` only accepted the initial-delay argument, and the interval between probes and the number of probes before the connection was declared dead were OS defaults. On Linux the defaults are 75 seconds between probes and 9 probes before drop, which means a half-open connection survives for ~11 minutes; on macOS the defaults are similar. Library authors (database drivers, message brokers, edge runtimes, QUIC clients) could not tune these without dropping to a native module. With the new options, the application code can shorten the probe interval to seconds and the count to a small number, which is the configuration the production database drivers have wanted for years. The companion [PR #63951](https://github.com/nodejs/node/pull/63951) adds `net.BoundSocket`, a synchronous early-TCP binding primitive for code paths that need to bind a port before yielding to the event loop." - question: "What does the release stabilize on the crypto side?" answer: "[PR #63924](https://github.com/nodejs/node/pull/63924) (Filip Skokan) marks `crypto.argon2` (Argon2id, Argon2i, Argon2d) and `crypto.encap` / `crypto.decap` (key encapsulation for ML-KEM and RSA-OAEP) as stable. Both have been behind an experimental flag since the 22.x cycle, and the stabilization is the prerequisite for libraries to depend on them without the `--experimental-argon2` and `--experimental-encap-decap` flags. The release also adds WebCrypto cSHAKE support ([PR #63988](https://github.com/nodejs/node/pull/63988), Filip Skokan), aligning Node.js with the same cSHAKE that the [Node.js 24.18.0 LTS Web Crypto work](/articles/2026-06-24--node-js-24-18-krypton-lts-buffer-pool-turboshake) extended. net.BlockList advances to Release Candidate stability ([PR #63050](https://github.com/nodejs/node/pull/63050), alphaleadership), the last step before stable in the next Current release." - question: "What is the fast FFI work, and why is it in 26.x Current rather than LTS?" answer: "[PR #63068](https://github.com/nodejs/node/pull/63068) and [PR #63941](https://github.com/nodejs/node/pull/63941) (Paolo Insogna) add an experimental fast FFI call API for AArch64 and x86_64. The work exposes a `node:ffi` module that lets JavaScript call native C functions without going through `node-addon-api`, with the cost of an indirect call instead of the V8 / libuv / N-API / nan round-trip that the existing addon path takes. The benchmark in the PR description cites roughly 50% of the call latency of the existing addon path on x86_64 Linux. The feature is in 26.x Current first because the API surface (calling convention, libffi backend wiring, lifetime rules) is still being shaped; the [follow-up PR #63794](https://github.com/nodejs/node/pull/63794) ports the same machinery to riscv64 and other architectures. Production users on the v24 LTS line do not need to act; the path is gated behind `--experimental-ffi` and the API will go through at least one Current cycle before it is a candidate for the LTS line." - question: "What QUIC work ships in 26.4.0?" answer: "Three QUIC changes land on the Current line. [PR #63536](https://github.com/nodejs/node/pull/63536) (James M Snell) adds a `listEndpoints` API that returns the local UDP endpoints currently in use by the QuicEndpoint. [PR #63191](https://github.com/nodejs/node/pull/63191) (Tim Perry) changes the QUIC certificate accessor to return a JavaScript `X509Certificate` handle instead of the raw OpenSSL handle that the earlier alpha exposed, which closes a long-standing complaint from QUIC users who wanted to inspect the certificate chain without going through `tls.getPeerCertificate`. [PR #63946](https://github.com/nodejs/node/pull/63946) and [PR #63950](https://github.com/nodejs/node/pull/63950) (Tim Perry) fix two real bugs: a `get_reader` issue that dropped data on FIN, and a reader-backpressure deadlock on idle connections. The QUIC work sits on top of the [Node.js 24.18.0 libuv reuse-port follow-up](/articles/2026-06-24--node-js-24-18-krypton-lts-buffer-pool-turboshake) and the QUIC CI work that has been landing on the v24 line for two months." - question: "What should users on Node.js 24 LTS do today?" answer: "Nothing changes for production users on the v24 LTS line; v26.4.0 is the Current line and the new features (VFS, package maps, TLS certificate compression, fast FFI) will take months to backport. The v24.18.0 release that shipped two days ago is still the recommended stable target. The two follow-ups worth watching on the v24 side are the VFS subsystem (which will eventually make its way into the LTS line) and the TLS certificate compression (which the [Node.js June 2026 security release](/articles/2026-06-18--node-js-june-2026-security-releases) covered for the v22 line). The v24.18.0 LTS line will pick these up when the Current line stabilizes them, which is the same cycle that produced the [Buffer.poolSize 64 KiB default](/articles/2026-06-03--node-js-26-3-0-buffer-pool-permission-drop) on v24.18.0 after two months on Current." - question: "What else ships in 26.4.0?" answer: "Several smaller pieces are worth flagging. [PR #63634](https://github.com/nodejs/node/pull/63634) (Matteo Collina) adds caller-supplied buffer support to `fs.readFile` and `fs.readFileSync`, the first time the file read API lets the caller pass in the destination buffer instead of letting Node.js allocate internally. [PR #63470](https://github.com/nodejs/node/pull/63470) (semimikoh) makes `http.closeIdleConnections` close pre-request sockets too, fixing a real bug where idle keep-alive sockets held a connection open after the request that owned them had completed. npm ships 11.17.0 ([PR #63857](https://github.com/nodejs/node/pull/63857)), sqlite updates to 3.53.2, libffi updates to 3.6.0 ([PR #64040](https://github.com/nodejs/node/pull/64040)), and acorn updates to 8.17.0. The release also marks [Node.js 25 as End-of-Life in the documentation](https://github.com/nodejs/node/pull/63692) and updates the Satteri package hash for the V8 precise coverage work that landed on the [Node.js 24.18.0 LTS line](/articles/2026-06-24--node-js-24-18-krypton-lts-buffer-pool-turboshake)." --- [Node.js 26.4.0 'Current'](https://github.com/nodejs/node/releases/tag/v26.4.0), published 2026-06-24 23:38 UTC by @aduh95 with @aduh95, @targos, and @jasnell as release stewards, is the second Current release of June on the v26 line and the largest of the cycle since [26.3.0](/articles/2026-06-03--node-js-26-3-0-buffer-pool-permission-drop) on 2026-06-01. It lands eight SEMVER-MINOR changes: a minimal [node:vfs subsystem](https://github.com/nodejs/node/pull/63115) (Matteo Collina) plus a follow-up that dispatches `node:fs/promises` to mounted VFS instances ([PR #63537](https://github.com/nodejs/node/pull/63537)), [package maps for ESM loader hooks](https://github.com/nodejs/node/pull/62239) (Maël Nison, the Yarn creator), [TLS certificateCompression](https://github.com/nodejs/node/pull/62217) on top of the OpenSSL compression work (Tim Perry), `TCP_KEEPINTVL` and `TCP_KEEPCNT` in [net.Socket.setKeepAlive](https://github.com/nodejs/node/pull/63825) (Guy Bedford), caller-supplied buffers in `fs.readFile` ([PR #63634](https://github.com/nodejs/node/pull/63634), Matteo Collina), `closeIdleConnections` that now also drops pre-request sockets ([PR #63470](https://github.com/nodejs/node/pull/63470), semimikoh), `net.BlockList` advanced to Release Candidate stability ([PR #63050](https://github.com/nodejs/node/pull/63050)), and `crypto.argon2` plus `crypto.encap` / `crypto.decap` marked stable ([PR #63924](https://github.com/nodejs/node/pull/63924), Filip Skokan). The release lands two days after [Node.js 24.18.0 'Krypton' (LTS)](https://github.com/nodejs/node/releases/tag/v24.18.0) on 2026-06-23, and the timing is the usual pattern: the Current line carries the experimental work that eventually backports to LTS. The [Buffer.poolSize 64 KiB default](/articles/2026-06-03--node-js-26-3-0-buffer-pool-permission-drop) is the canonical example, having shipped on Current in [26.3.0](/articles/2026-06-03--node-js-26-3-0-buffer-pool-permission-drop) on 2026-06-01 and on LTS in 24.18.0 two days ago. The VFS subsystem, the package maps for ESM loaders, and the TLS certificate compression are the same kind of work: significant enough that they earn their own Current release, but still experimental enough that they will not reach the v24 LTS line for at least one more cycle. ## `node:vfs`, a new core subsystem The most architecturally significant change in 26.4.0 is the new `node:vfs` subsystem. [PR #63115](https://github.com/nodejs/node/pull/63115) (Matteo Collina) adds a minimal in-process VFS layer that application code can mount and unmount at runtime. The subsystem exposes four functions: `mount(prefix, vfsInstance)`, `unmount(prefix)`, `getMount(prefix)`, and `getMounts()`. The `vfsInstance` is a JavaScript object that implements a small async interface (`readFile`, `stat`, `readdir`, plus a handful of others), and Node.js dispatches `node:fs/promises` calls whose path starts with the mounted prefix to the instance instead of the OS filesystem. The follow-up [PR #63537](https://github.com/nodejs/node/pull/63537) (Matteo Collina) wires the layer into `node:fs/promises` directly. A `readFile('/vfs/project/src/index.ts')` call on a prefix that has been mounted with an in-memory VFS instance that contains the project tree returns the in-memory contents without touching disk. The integration is the runtime-side foundation for sandboxed execution: build tools can hand a loader a virtual filesystem that contains the project tree, serverless platforms can hand a request handler a virtual filesystem that contains only the request scope, IDE language servers can hand a debugger probe a virtual filesystem that contains the file being debugged. Production users on the v24 LTS line will not see this for at least one release cycle, but the Current line now has the primitive that the next round of tooling work will sit on. The VFS instance interface is intentionally minimal in this first cut. The PR description is explicit that symlinks, file watching, and real-path resolution are out of scope and will land in follow-up Current releases. The companion documentation PR describes the surface as "the smallest viable VFS that lets us replace ad-hoc fs monkey-patching in tooling" and notes that the API will go through at least one Current cycle before it is a candidate for stabilization. ## Package maps for ESM loader hooks The second architectural change is [PR #62239](https://github.com/nodejs/node/pull/62239) (Maël Nison), which implements package maps for ESM loader hooks. The runtime already has a `package.json`-style `imports` map that lets the application graph resolve bare specifiers (`#internal/api`, `lodash/sortBy`, `react/jsx-runtime`); loader hooks previously had to re-implement the map lookup themselves because the resolution was internal to the module loader. The new API exposes the same resolution as a first-class call on the loader hooks, so a loader that needs to know whether a specifier resolves to a remapped path (or to a subpath) can read the result directly without walking the `package.json` itself. For build tool authors, this is the missing piece for implementing Node.js-compatible import maps on top of a bundler. The [import-map spec](https://html.spec.whatwg.org/multipage/webappapis.html#import-maps) already defines the wire format, and the browser implementations have shipped import maps for years. Node.js has had the underlying `imports` field for the same period, but the loader hooks API never exposed the resolution path that the host runtime used; loader authors had to walk the `package.json` and re-implement the map. Maël Nison, who authored the Yarn package manager and was the primary contributor to the [Yarn `resolutions`](https://classic.yarnpkg.com/lang/en/docs/selective-version-resolutions/) mechanism, is the right author for this work, and the PR is the first time the ESM loader hooks expose the package map machinery as a first-class API. The PR description frames it as the loader hooks side of the same import-map work that [Vite 8.1's `build.chunkImportMap`](https://github.com/vitejs/vite/releases/tag/v8.1.0) ships at the build-output layer (covered in our [Vite 8.1 stable piece](/articles/2026-06-24--vite-8-1-stable-bundled-dev-mode)). Vite 8.1's chunkImportMap is a bundler-side feature that emits a browser import map for chunk URL resolution; 26.4.0's loader package maps are the host-runtime side that a bundler would consume when running in Node.js. The two pieces are independently useful, but they sit at different layers of the same stack. ## TLS certificate compression The third SEMVER-MINOR change is [PR #62217](https://github.com/nodejs/node/pull/62217) (Tim Perry), which adds a `certificateCompression` option to `tls.createSecureContext` and `https.Server`. The option takes an array of compression algorithms (`'zlib'` and `'zstd'`), and the PR wires the [RFC 8879](https://www.rfc-editor.org/rfc/rfc8879) extension through the OpenSSL build config so the compression primitives are linked into the Node.js binary. The companion commit `e44b5d487e` updates the OpenSSL build config to support compression; without that, the OpenSSL-side support would not be available to the Node.js TLS layer. TLS certificate compression is most useful when the chain includes a large post-quantum signature, which is the same reason Chrome and Firefox have been rolling it out over the past year. Servers that enable it on a chain that includes an ML-DSA-65 or ML-DSA-87 signature (the NIST FIPS 204 primary signatures) should see a noticeably shorter TLS handshake. The PR is also the first time the OpenSSL build path exposes the same TLS surface that the [BoringSSL path already supports](https://github.com/nodejs/node/pull/63255), which means a single Node.js binary can serve the same `certificateCompression` option regardless of which TLS backend it was built against. ## `TCP_KEEPINTVL` and `TCP_KEEPCNT` in `setKeepAlive` The fourth SEMVER-MINOR change is [PR #63825](https://github.com/nodejs/node/pull/63825) (Guy Bedford), which adds `TCP_KEEPINTVL` and `TCP_KEEPCNT` to the options accepted by `net.Socket.setKeepAlive(enable, initialDelay)`. Before 26.4.0, `setKeepAlive` only accepted the initial-delay argument, and the interval between probes and the number of probes before the connection was declared dead were OS defaults. On Linux the defaults are 75 seconds between probes and 9 probes before drop, which means a half-open connection survives for ~11 minutes; on macOS the defaults are similar. Library authors (database drivers, message brokers, edge runtimes, QUIC clients) could not tune these without dropping to a native module. With the new options, the application code can shorten the probe interval to seconds and the count to a small number, which is the configuration the production database drivers have wanted for years. The companion [PR #63951](https://github.com/nodejs/node/pull/63951) (Guy Bedford) adds `net.BoundSocket`, a synchronous early-TCP binding primitive for code paths that need to bind a port before yielding to the event loop. The two pieces are the first substantial `net` changes on the v26 Current line and are the same family as the [TCP keep-alive work](https://github.com/nodejs/node/pull/63155) that the [Node.js 24.18.0 LTS line](/articles/2026-06-24--node-js-24-18-krypton-lts-buffer-pool-turboshake) shipped. ## Crypto stabilization, QUIC, dgram, and FFI The other five SEMVER-MINOR pieces complete the picture. [PR #63924](https://github.com/nodejs/node/pull/63924) (Filip Skokan) marks `crypto.argon2` (Argon2id, Argon2i, Argon2d) and `crypto.encap` / `crypto.decap` (key encapsulation for ML-KEM and RSA-OAEP) as stable. Both have been behind an experimental flag since the 22.x cycle, and the stabilization is the prerequisite for libraries to depend on them without the flags. The release also adds WebCrypto cSHAKE support ([PR #63988](https://github.com/nodejs/node/pull/63988), Filip Skokan), which extends the [Web Crypto cSHAKE work](/articles/2026-06-24--node-js-24-18-krypton-lts-buffer-pool-turboshake) that shipped on the v24 line. `net.BlockList` advances to Release Candidate stability ([PR #63050](https://github.com/nodejs/node/pull/63050), alphaleadership), the last step before stable in the next Current release. On the QUIC side, [PR #63536](https://github.com/nodejs/node/pull/63536) (James M Snell) adds a `listEndpoints` API and [PR #63191](https://github.com/nodejs/node/pull/63191) (Tim Perry) changes the certificate accessor to return an `X509Certificate` handle instead of the raw OpenSSL handle. `dgram` gets synchronous `connectSync` and `bindSync` ([PRs #63838](https://github.com/nodejs/node/pull/63838) + [#63932](https://github.com/nodejs/node/pull/63932), Guy Bedford). The experimental fast FFI work ([PR #63068](https://github.com/nodejs/node/pull/63068) + [PR #63941](https://github.com/nodejs/node/pull/63941), Paolo Insogna) lands for AArch64 and x86_64, with the [follow-up PR #63794](https://github.com/nodejs/node/pull/63794) (Stewart X Addison) porting the same machinery to riscv64. The path is gated behind `--experimental-ffi` and the API will go through at least one Current cycle before it is a candidate for the LTS line. ## Other changes in 26.4.0 The release ships a long tail of smaller changes. [PR #63634](https://github.com/nodejs/node/pull/63634) (Matteo Collina) adds caller-supplied buffer support to `fs.readFile` and `fs.readFileSync`, the first time the file read API lets the caller pass in the destination buffer instead of letting Node.js allocate internally. [PR #63470](https://github.com/nodejs/node/pull/63470) (semimikoh) makes `http.closeIdleConnections` close pre-request sockets too, fixing a real bug where idle keep-alive sockets held a connection open after the request that owned them had completed. npm ships 11.17.0 ([PR #63857](https://github.com/nodejs/node/pull/63857)), sqlite updates to 3.53.2, libffi updates to 3.6.0 ([PR #64040](https://github.com/nodejs/node/pull/64040)), and acorn updates to 8.17.0. The release also marks [Node.js 25 as End-of-Life in the documentation](https://github.com/nodejs/node/pull/63692) and ships a long stream optimization patch (Matteo Collina, James M Snell, Trivikram Kamat) that reduces allocations on the WHATWG streams hot paths, fixes the Utf8Stream stall after a full write of multi-byte data, and refines the `stream/iter` backpressure. The companion [PR #62986](https://github.com/nodejs/node/pull/62986) fixes `Writable.toWeb()` `desiredSize` for non-object-mode streams, a long-standing bug that surfaced whenever the WHATWG streams adapter was used with a binary stream. The full [Node.js 26 release schedule](https://github.com/nodejs/release) projects Current maintenance through October 2026, at which point v26 enters Active LTS. Production users on the v24 LTS line should stay on 24.18.0 (the [Node.js 24.18.0 'Krypton' LTS release](/articles/2026-06-24--node-js-24-18-krypton-lts-buffer-pool-turboshake) we covered two days ago) for at least the next quarter; the v24.19.0 follow-up will pick up the experimental work from 26.x Current as it stabilizes.