CVE-2026-92938

vm2 versions 3.11.3 through 3.11.6 expose Node.js's host node:sqlite module to code running in NodeVM when that builtin is permitted, either explicitly or through builtin: ['*']. The module is wrapped with vm.readonly(), which prevents property assignment but leaves host-authority callables reachable; in addition, the resolver treats any request starting with 'node:' as a core-module request and the runtime strips only one 'node:' prefix, so a sandbox request for 'node:node:sqlite' resolves to the configured node:sqlite entry. Sandboxed code can therefore create an in-memory DatabaseSync with extension loading enabled and call DatabaseSync.loadExtension() on a native library bundled in the untrusted plugin package (path derived from __dirname). SQLite loads the library into the Node.js host process and invokes its native entry point, giving the sandboxed plugin arbitrary native code execution outside the sandbox with the host process's privileges. The issue is fixed in vm2 3.11.7.

vm2 versions 3.11.3 through 3.11.6 expose Node.js's host node:sqlite module to code running in NodeVM when that builtin is permitted, either explicitly or through builtin: ['*']. The module is wrapped with vm.readonly(), which prevents property assignment but leaves host-authority callables reachable; in addition, the resolver treats any request starting with 'node:' as a core-module request and the runtime strips only one 'node:' prefix, so a sandbox request for 'node:node:sqlite' resolves to the configured node:sqlite entry. Sandboxed code can therefore create an in-memory DatabaseSync with extension loading enabled and call DatabaseSync.loadExtension() on a native library bundled in the untrusted plugin package (path derived from __dirname). SQLite loads the library into the Node.js host process and invokes its native entry point, giving the sandboxed plugin arbitrary native code execution outside the sandbox with the host process's privileges. The issue is fixed in vm2 3.11.7.

Summary

vm2 3.11.6 exposes Node.js's host node:sqlite module to NodeVM code when that builtin is allowed explicitly or through builtin: ['*']. The module is wrapped as read-only, but callable methods retain host-process authority. A sandboxed plugin can construct an in-memory database with extension loading enabled and call DatabaseSync.loadExtension() on a native library bundled in the plugin directory.

SQLite loads the library into the Node.js host process and invokes its native extension entry point. This gives the untrusted plugin arbitrary native code execution outside the sandbox.

The exploit needs only the node:sqlite builtin and a compatible native library already present in the untrusted plugin package. It does not require fs, process, module, child_process, worker_threads, vm, inspector, vm2 nesting, or an existing database file.

Details

The vulnerable boundary spans the builtin inventory, resolver, runtime loader, and generic read-only wrapper.

On current Node.js versions, the builtin inventory contains the literal name node:sqlite. vm2 admits that name when it is explicitly configured or when the wildcard allowlist is expanded:

const BUILTIN_MODULES = module.builtinModules.filter(/* denylist checks */);

The resolver then treats every request beginning with node: as a core-module request, even if the complete request string is not an allowlist key:

if (x.startsWith('node:') || this.builtins.has(x)) {
  return x;
}

The sandbox runtime removes exactly one node: prefix and looks up the remainder in the configured builtin map:

if (filename.startsWith('node:')) {
  id = filename.slice(5);
  return loadBuiltinModule(id);
}

Consequently, the sandbox spelling below resolves to the configured map entry node:sqlite:

require('node:node:sqlite')

The default builtin loader imports the real module in the host realm and exposes it through vm.readonly():

builtins.set(key, vm => vm.readonly(hostRequire(key)));

Read-only wrapping prevents property assignment. It does not remove dangerous callable capabilities. Calls to DatabaseSync and loadExtension() are forwarded to the host implementation.

The complete exploit flow is:

attacker supplies an untrusted plugin package containing JavaScript and a native library
  -> host runs the JavaScript in NodeVM with node:sqlite allowed
  -> plugin resolves the host module as node:node:sqlite
  -> plugin creates an in-memory DatabaseSync with allowExtension enabled
  -> plugin derives the bundled library path from its own __dirname
  -> plugin calls database.loadExtension(libraryPath)
  -> vm2 forwards the call to host SQLite
  -> SQLite loads the library into the Node.js host process
  -> SQLite invokes the library's native extension entry point
  -> attacker native code executes with the host process's privileges

The path does not need to be read through a sandboxed filesystem API. CommonJS already supplies the plugin's own directory, so an attacker can concatenate __dirname with the known name of a bundled library. The host necessarily places the untrusted plugin package on disk before evaluating its JavaScript.

PoC

The attached PoC is local and harmless. Its native extension entry point writes one marker file and returns success. It does not launch a process, connect to a network service, or modify any other file.

Prerequisites: macOS, Node.js with node:sqlite, npm, and a C compiler.

1. Open the attached poc directory.

2. Install the exact affected package:

   npm install --ignore-scripts
   

3. Compile and run the proof:

   npm run poc
   

The script compiles extension_probe.c as libvm2_sqlite_probe.dylib, then runs untrusted-plugin.js in this restrictive configuration:

new NodeVM({
  console: 'off',
  require: { builtin: ['node:sqlite'] },
});

The sandboxed plugin performs only:

const {…

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-6w8r-xxw2-g3hx. This link is maintained to preserve external references.

Original Description

vm2 versions 3.11.3 through 3.11.6 expose Node.js's host node:sqlite module to code running in NodeVM when that builtin is permitted, either explicitly or through builtin: ['*']. The module is wrapped with vm.readonly(), which prevents property assignment but leaves host-authority callables reachable; in addition, the resolver treats any request starting with 'node:' as a core-module request and the runtime strips only one 'node:' prefix, so a sandbox request for 'node:node:sqlite' resolves to the configured node:sqlite entry. Sandboxed code can therefore create an in-memory DatabaseSync with extension loading enabled and call DatabaseSync.loadExtension() on a native library bundled in the untrusted plugin package (path derived from __dirname). SQLite loads the library into the Node.js host process and invokes its native entry point, giving the sandboxed plugin arbitrary native code execution outside the sandbox with the host process's privileges. The issue is fixed in vm2 3.11.7.

vm2 versions 3.11.3 through 3.11.6 expose Node.js's host node:sqlite module to code running in NodeVM when that builtin is permitted, either explicitly or through builtin: ['*']. The module is wrapped with vm.readonly(), which prevents property assignment but leaves host-authority callables reachable; in addition, the resolver treats any request starting with 'node:' as a core-module request and the runtime strips only one 'node:' prefix, so a sandbox request for 'node:node:sqlite' resolves to the configured node:sqlite entry. Sandboxed code can therefore create an in-memory DatabaseSync with extension loading enabled and call DatabaseSync.loadExtension() on a native library bundled in the untrusted plugin package (path derived from __dirname). SQLite loads the library into the Node.js host process and invokes its native entry point, giving the sandboxed plugin arbitrary native code execution outside the sandbox with the host process's privileges. The issue is fixed in vm2 3.11.7.

vm2 versions 3.11.3 through 3.11.6 expose Node.js's host node:sqlite module to code running in NodeVM when that builtin is permitted, either explicitly or through builtin: ['*']. The module is wrapped with vm.readonly(), which prevents property assignment but leaves host-authority callables reachable; in addition, the resolver treats any request starting with 'node:' as a core-module request and the runtime strips only one 'node:' prefix, so a sandbox request for 'node:node:sqlite' resolves to the configured node:sqlite entry. Sandboxed code can therefore create an in-memory DatabaseSync with extension loading enabled and call DatabaseSync.loadExtension() on a native library bundled in the untrusted plugin package (path derived from __dirname). SQLite loads the library into the Node.js host process and invokes its native entry point, giving the sandboxed plugin arbitrary native code execution outside the sandbox with the host process's privileges. The issue is fixed in vm2 3.11.7.