Live › vulnerability › CVE-2026-24118
vm2 is a Node.js library that runs untrusted JavaScript in a sandbox. A flaw in how __lookupGetter__ crosses between sandbox and host lets sandboxed code reach the host Function constructor and run arbitrary shell commands on the server.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-11-04 03:31 UTC, 0h before NVD. All times on this page are UTC.
Only applications that use vm2 to run code they do not fully trust (user scripts, plugins, or code submitted through an API) are exposed, because the sandbox is the security boundary. Applications that only run vm2 on code they wrote themselves are at much lower risk. The sources do not say whether the flaw needs a particular vm2 API or configuration beyond running code inside the sandbox.
| Product | Ecosystem | Affected | Fixed in |
|---|---|---|---|
| vm2 | npm | < 3.11.0 | 3.11.0 |
| vm2 project vm2 | vendor | < 3.11.0 | 3.11.0 |
npm ls vm2 in each project to see whether vm2 is installed and at what version.package-lock.json, yarn.lock, ) for .pnpm-lock.yamlvm2new VM() or NodeVM from vm2.3.11.0 (fixed version; earlier versions are affected)Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
VM2 suffers from a sandbox breakout vulnerability. This allows attackers to write code which can escape from the VM2 sandbox and execute arbitrary commands on the host system.
The __lookupGetter__ method allows to read the getter of an object. It is special in VM2 since it will switch between the host and sandbox version of the method when passed to the other context.
This allows to access getters on an object in the host context if the method is called from the host context which can be achieved by using the host apply method which can be accessed through Buffer.apply.
Afterwards, this function can be used to call the host version of __lookupGetter__ with Buffer and __proto__ resulting in the prototype lookup method from the host context.
With this method the hosts Function.prototype object can be retrieved and the host Function acquired through the constructor property which allows to create and run code in the host context.
This issue was attempted to be fixed with https://github.com/patriksimek/vm2/blob/4b009c2d4b1131c01810c1205e641d614c322a29/lib/bridge.js#L427. However, this can be circumvented by using Object.getOwnPropertyDescriptor to get the constructor property.
The following code demonstrates this issue by acquiring the host process object and executing touch pwned.
const {VM} = require("vm2");
const vm = new VM();
vm.run(`
const g = ({}).__lookupGetter__;
const a = Buffer.apply;
const p = a.apply(g, [Buffer, ['__proto__']]);
Object.getOwnPropertyDescriptor(p.call(a),'constructor').value('return process')().mainModule.require('child_process').execSync('touch pwned');
`);
Attackers can perform Remote Code Execution under the assumption that arbitrary code can be executed inside the context of a vm2 sandbox.
This page as .md · .json · in your agent: get_signal("CVE-2026-24118")
GitHub Advisory Database, CC-BY 4.0 · NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.