vm2 sandbox had a hole big enough to drive a shell through - CVE-2026-93605 explained

A newly disclosed flaw in vm2, a popular Node.js sandboxing library, has been rated the maximum possible severity - a CVSS score of 10.0. The bug, tracked as CVE-2026-93605, lets code running inside a supposedly locked-down sandbox reach straight out and run commands on the host machine. That’s about as bad as it gets for something whose entire job is to stop exactly that.

What the bug actually does

vm2’s NodeVM feature is designed to run untrusted JavaScript in isolation, blocking access to Node’s more dangerous built-in modules. According to the GitHub security advisory, the maintainers built a denylist called DANGEROUS_BUILTINS that blocks modules like worker_threads, cluster, vm, process and several others - all modules that could theoretically let sandboxed code touch the host system.

The problem is what’s missing from that list: child_process. That’s the Node module whose entire purpose is spawning system commands - arguably the single most direct route to remote code execution available in the platform. Per VulnCheck’s writeup, any sandbox configured with require:{builtin:['*']}, or otherwise permitting broad or explicit access to built-ins, could simply require('child_process') and call something like execSync to run arbitrary commands on the host - no cleverness required beyond reading the missing entry.

The NVD listing confirms the CVSS 4.0 vector rates this as remotely exploitable with low complexity, no privileges and no user interaction needed, and full impact on confidentiality, integrity and availability. In plain terms: if your setup is affected, an attacker doesn’t need to trick anyone or already have a foothold - they just need to get code into the sandbox.

So who is actually at risk

This affects vm2’s NodeVM versions up to and including 3.12.0, specifically when it’s configured to allow broad built-in module access (the ['*'] pattern or explicit child_process allowance) rather than a tightly restricted allowlist. If you don’t use vm2, or you use it but never enable broad built-in access, this doesn’t touch you.

The people who need to pay attention are developers and organisations who embed vm2’s NodeVM to execute untrusted or third-party JavaScript - think plugin systems, code-execution features in SaaS products, or CI-style tooling that runs user-submitted scripts. If that’s not your stack, there’s nothing to do here.

Notably absent from the published material is any confirmation of active exploitation in the wild, or install-base figures for how many projects actually run vm2’s NodeVM with the risky configuration. Treat the CVSS 10.0 as a worst-case technical ceiling, not evidence of a live attack wave.

What to do about it

The fix is version 3.12.1, which patches the denylist to properly cover child_process. If you maintain or deploy anything using vm2’s NodeVM, check your dependency version and update. If upgrading isn’t immediately possible, avoid granting sandboxes broad or wildcard built-in module access, and specifically ensure child_process isn’t reachable.

The takeaway

This is a real, maximum-severity flaw with a clear fix already available - not a hypothetical. But it only bites a specific configuration of a specific library, not the internet at large. If you run vm2’s NodeVM, patch it today. If you don’t, this is one to note and move on from.