No advisories yet.
Solution
No solution given by the vendor.
Workaround
No workaround given by the vendor.
Sat, 19 Sep 2026 03:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
ssvc
|
Thu, 17 Sep 2026 23:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| First Time appeared |
Patriksimek
Patriksimek vm2 |
|
| Vendors & Products |
Patriksimek
Patriksimek vm2 |
Thu, 17 Sep 2026 14:00:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| 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. | |
| Title | vm2 3.11.3 through 3.11.6 Remote Code Execution via node:sqlite | |
| Weaknesses | CWE-693 | |
| References |
| |
| Metrics |
cvssV3_1
|
Projects
Sign in to view the affected projects.
Status: PUBLISHED
Assigner: VulnCheck
Published:
Updated: 2026-09-19T02:28:41.247Z
Reserved: 2026-09-17T12:42:34.828Z
Link: CVE-2026-92938
Updated: 2026-09-19T02:28:36.823Z
Status : Deferred
Published: 2026-09-17T14:17:58.750
Modified: 2026-09-19T03:17:18.443
Link: CVE-2026-92938
No data.
OpenCVE Enrichment
Updated: 2026-09-17T23:45:17Z