Node.js 26.9.0 turns on node:ffi by default, six weeks before Node 26 becomes LTS

Node.js 26.9.0, released September 16, makes the node:ffi module available without a flag. The change is PR #65475, "ffi: enable module by default," by Matteo Collina, merged August 28. Its description is short:

Enable node:ffi by default in builds with FFI support. Keep --experimental-ffi as a compatibility no-op and --no-experimental-ffi as an opt-out.

PR #65475

node:ffi arrived in v26.1.0 as a foreign function interface: load a shared library, look up a symbol, call it from JavaScript. Until now it needed --experimental-ffi on the command line. From 26.9.0 it needs nothing.

What it does, in one call

The module's own documentation is blunt about it: "This API is unsafe. Passing invalid pointers, using an incorrect symbol signature, or accessing memory after it has been freed can crash the process or corrupt memory."

"Builds with FFI support" includes the official binary. We downloaded node-v26.9.0-linux-x64.tar.xz from nodejs.org, checked it against the published SHA-256 sum, and ran it with no flags. process.config.variables.node_use_ffi reported true, and this called libc directly:

const { DynamicLibrary } = require('node:ffi');
const libc = new DynamicLibrary('libc.so.6');
const getpid = libc.getFunction('getpid', { arguments: [], return: 'int32' });
console.log(getpid(), process.pid);   // printed the same PID twice

The only friction was one line on stderr: ExperimentalWarning: FFI is an experimental feature and might change at any time. The module is still at "Stability: 1 - Experimental"; what changed is that it no longer needs a flag.

Where the gate is now

There are two ways to turn it off, and we tested both on the same binary:

$ node --no-experimental-ffi -e "require('node:ffi')"
Error [ERR_UNKNOWN_BUILTIN_MODULE]: No such built-in module: node:ffi

$ node --permission -e "require('node:ffi').dlopen('libc.so.6')"
Error [ERR_ACCESS_DENIED]: Access to this API has been restricted. Use --allow-ffi to manage permissions.

--no-experimental-ffi also works through NODE_OPTIONS: the PR adds it to the documented list of options allowed there, and NODE_OPTIONS=--no-experimental-ffi gave the same ERR_UNKNOWN_BUILTIN_MODULE in our test. Under the permission model, passing --allow-ffi restores access and prints its own warning: "The flag --allow-ffi must be used with extreme caution. It could invalidate the permission model."

Why a server operator should care

A process started without --permission could already load native code. Addons are allowed by default, and child_process is there too. So the flag change does not add a capability that an unrestricted Node process lacked. What it removes is the artifact. Before, calling into a C library from a package meant shipping a compiled .node addon or a build step. Now it is a require('node:ffi') in plain JavaScript. That last point is our inference, not something the Node project says: review and scanning that watch for native addons in dependencies will not see this route. Searching a dependency tree for the string node:ffi will.

The timing matters too. The project's release schedule puts Node 26 into LTS on 2026-10-28, six weeks after this release. Nothing we read says whether FFI will stay on by default when 26 becomes LTS. As of 26.9.0 it is on, and the flag that used to enable it is now a no-op.

What to do

• If you run Node 26 in production and do not use FFI, add --no-experimental-ffi (or set it in NODE_OPTIONS) now, before the LTS line makes 26 the default upgrade target.
• If you already use --permission, nothing changes: FFI stays denied until you add --allow-ffi.
• grep -r "node:ffi" node_modules is a cheap check to add to dependency review.

Primary sources: Node.js 26.9.0 release notes, PR #65475, node:ffi documentation at v26.9.0, CLI documentation at v26.9.0, Node.js release schedule, official v26.9.0 binary, tested and read 2026-09-25.