CVE-2026-92938

### 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(ke