vm2 3.11.3 through 3.11.6 Remote Code Execution via node:sqlite

CISA KEV is observed exploitation evidence. FIRST EPSS is a dated prediction of exploitation in the next 30 days. Missing scores are unknown. This collector requests predictions only for explicit CVE aliases in the public NuGet archive; Microsoft release views retain their existing prediction scope.

No collected risk observation for these identifiers. This does not establish absence of exploitation or a zero probability.

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.

Source published

17 Sep 2026 13:46:02 UTC

Source modified

19 Sep 2026 02:28:41 UTC

Observed here

23 Oct 2026 15:48:27 UTC

Source terms

CVE Program Terms of Use

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: cve-program · CVE Program Terms of Use. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 4.0 · 9.4 CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

CVSS 3.1 · 9.9 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

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.

Source published

Sep 17, 2026, 1:46:02 PM (timezone not stated)

Source modified

Sep 19, 2026, 2:28:41 AM (timezone not stated)

Observed here

11 Nov 2026 17:05:08 UTC

Source terms

ENISA EUVD · source terms and attribution apply

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: euvd · ENISA EUVD · source terms and attribution apply. Source text is retained; field grouping and change labels are provided by ChangeIntel.

EUVD CVSS 4.0 · 9.4 CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

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.

Source published

17 Sep 2026 14:17:58 UTC

Source modified

19 Sep 2026 03:17:18 UTC

Observed here

25 Oct 2026 16:19:22 UTC

Source terms

NIST NVD usage terms; underlying source attribution retained

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: nvd · NIST NVD usage terms; underlying source attribution retained. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 4.0 · [email protected] · Secondary · 9.4 CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

CVSS 3.1 · [email protected] · Secondary · 9.9 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

### 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: ```js 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: ```js 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: ```js if (filename.startsWith('node:')) { id = filename.slice(5); return loadBuiltinModule(id); } ``` Consequently, the sandbox spelling below resolves to the configured map entry `node:sqlite`: ```js require('node:node:sqlite') ``` The default builtin loader imports the real module in the host realm and exposes it through `vm.readonly()`: ```js 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: ```text 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: ```bash npm install --ignore-scripts ``` 3. Compile and run the proof: ```bash npm run poc ``` The script compiles `extension_probe.c` as `libvm2_sqlite_probe.dylib`, then runs `untrusted-plugin.js` in this restrictive configuration: ```js new NodeVM({ console: 'off', require: { builtin: ['node:sqlite'] }, }); ``` The sandboxed plugin performs only: ```js const { DatabaseSync } = require('node:node:sqlite'); const database = new DatabaseSync(':memory:', { allowExtension: true }); database.loadExtension(__dirname + '/libvm2_sqlite_probe.dylib'); database.close(); ``` A vulnerable result is: ```json { "sandboxResult": { "nativeExtensionLoaded": true, "usedOnlySQLiteBuiltin": true }, "markerExists": true, "markerText": "VM2_SQLITE_EXTENSION_ENTRYPOINT_EXECUTED" } ``` The marker is written from the compiled native extension entry point, not from JavaScript. `loadExtension()` also returns successfully, proving that SQLite both loaded the library and invoked its entry point. ### Impact This is a sandbox escape to arbitrary native code execution. The native code runs inside the Node.js host process with the operating-system identity and privileges of that process, beyond all vm2 JavaScript, module, and proxy restrictions. An attacker can replace the marker-only extension with native code that: - reads application secrets, credentials, environment variables, and files available to the host account; - modifies application data or executable files and establishes persistence; - accesses internal services using the host's network identity; - steals other tenants' data from the same process; - terminates or corrupts the host process; and - performs any other operating-system action permitted to the host account. The realistic affected workflow is a plugin platform, automation service, notebook, build service, or multi-tenant code runner that stores attacker-supplied package contents and evaluates the package's JavaScript in `NodeVM` while allowing `node:sqlite` or all builtins. The attacker does not need pre-existing host execution, a writable database, or a command-execution builtin.

Source published

1 Oct 2026 15:29:04 UTC

Source modified

1 Oct 2026 15:45:06 UTC

Observed here

24 Oct 2026 13:17:17 UTC

Source terms

GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · GitHub Advisory Database · CC-BY-4.0. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS_V3 · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

Publisher rating · CRITICAL

## 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.

Source published

17 Sep 2026 15:32:14 UTC

Source modified

1 Oct 2026 15:45:06 UTC

Observed here

24 Oct 2026 13:17:17 UTC

Source terms

GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · GitHub Advisory Database · CC-BY-4.0. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS_V3 · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

CVSS_V4 · CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Publisher rating · CRITICAL