Critical flaw lets sandboxed code break out of vm2 and run commands on the host

A newly disclosed vulnerability in vm2, a JavaScript library used to run untrusted code inside a supposedly locked-down sandbox, has been rated the maximum possible severity: 10 out of 10 on the CVSS scale. Tracked as CVE-2026-93603, it lets script running inside the sandbox break out entirely and execute arbitrary commands on the host machine. That is about as bad as a bug gets — but whether it matters to you depends heavily on exactly how a piece of software is built.

What the bug actually does

vm2 is designed to let developers run code they don’t fully trust — plugins, user scripts, snippets in an online code runner — while keeping it walled off from the rest of the system. Part of how it does that is by controlling what happens when sandboxed code calls functions that the host application has deliberately exposed to it.

According to the GitHub security advisory, the fault sits in vm2’s “bridge” code (lib/bridge.js), which handles these calls. If a host-provided function is written in old-fashioned “non-strict” (sloppy-mode) JavaScript and the sandboxed code calls it without specifying a receiver — plain patterns like fn(), fn.call() or fn.bind()() — the JavaScript engine automatically substitutes the host’s own global object as this. vm2 was supposed to catch and neutralise that substitution, but instead passes it straight back into the sandbox. From there, sandboxed script gets a working handle on the host’s process object and, per VulnCheck’s write-up, can use something as mundane as child_process.execSync to run system commands.

The flaw affects vm2 versions up to and including 3.12.0, and is fixed in 3.12.1. It’s catalogued as CWE-94, “improper control of generation of code” — a code injection bug — and carries a CVSS v4 score of 10.0. It was credited to a researcher named RajChowdhury240 and published on 3 September 2026, with the NVD entry landing on 18 September.

So who is actually at risk

The crucial qualifier, buried in the technical detail, is this: exploitation requires the application embedding vm2 to expose at least one non-strict (old-style) host function directly into the sandbox. If the functions a developer hands to the sandbox are written in strict mode, or as ES modules — both increasingly the default in modern JavaScript — this particular attack path doesn’t work.

So this isn’t a bug that spontaneously endangers anyone simply for having vm2 installed. It’s a bug that matters specifically to developers who built sandboxing features on top of vm2 and passed old-style sloppy functions into that sandbox — a fairly common but not universal pattern, especially in tools like online code editors, plugin systems, bots, or notebook-style environments that let users run scripts against host-provided helpers. Neither the NVD entry, the GitHub advisory nor VulnCheck’s page states that the bug is being actively exploited in the wild; what’s confirmed is the flaw’s existence and severity, not evidence of attacks already under way.

What to do about it

If you maintain or run software that uses vm2 to sandbox untrusted code, the fix is straightforward: update to version 3.12.1 or later, where the nullish this handling has been corrected. It’s also worth auditing which host functions get exposed into the sandbox and, where practical, rewriting them in strict mode as extra insurance.

For everyone else — most ordinary users of apps and websites — this is invisible plumbing rather than an immediate personal risk. The people who need to act are the developers relying on vm2’s sandbox to hold; the rest of us just benefit, quietly, once they patch it.