vm2 Sandbox Escape: 12 Critical CVEs Hit Node.js Apps

Last week, security researchers disclosed twelve critical vulnerabilities in vm2, a popular Node.js library used to run untrusted JavaScript code inside a "safe" sandbox. Three of them carry a CVSS score of 10.0, which is as bad as a vulnerability score gets. Every single one of the twelve lets an attacker break out of the sandbox and execute arbitrary commands on the host machine. The fixes landed in version 3.11.2 on May 3rd.

If you have never heard of vm2, you might still be running it. It powers code execution features in low-code platforms, AI agent frameworks, plugin systems, online IDEs, and a long tail of LLM-generated apps where someone needed to "run user code safely" and grabbed the first npm package that looked right.

That is the part that matters for vibe-coded apps.

Why this hits vibe-coded apps harder

When a founder ships an MVP using AI-assisted coding, the model picks dependencies based on familiarity, not on threat modeling. vm2 has been the default answer to "how do I run untrusted JavaScript in Node" for years. AI coding assistants suggest it because Stack Overflow suggested it. Nobody in the loop pauses to ask whether the sandbox actually works.

Here is the uncomfortable part. vm2's own maintainer has been clear for a long time. The README literally tells you the library should not be used for production when handling fully untrusted code. New bypass techniques are expected. Twelve more just showed up to prove the point.

If your app does any of the following, you should check your dependencies today:

• Lets users paste code, formulas, or expressions that get executed
• Runs LLM-generated code as part of an agent loop
• Accepts plugins, custom rules, or user-defined scripts
• Uses a low-code or workflow tool that mentions "sandboxed JS"

Our take at VibeAudits

This is exactly the failure mode we keep finding in vibe-coded apps. The code reads clean. The tests pass. The demo works. And the entire security posture sits on top of a library whose own author has publicly said the security model is fundamentally limited.

Vibe coding hides this. The model does not warn you that the sandbox you just adopted has a nine year history of escape bugs. It does not tell you the maintainer recommends migrating to isolated-vm or to process-level isolation. You find out when a researcher publishes a CVE, or worse, when an attacker does not bother to publish one.

What to do this week

1. Run npm ls vm2 across every Node project in your stack. Check direct and transitive dependencies. Anything at or below 3.11.1 needs to move to 3.11.2 immediately.
2. If you are running genuinely untrusted code, do not rely on vm2 alone. Move to isolated-vm, a separate worker process, a Docker container, or a microVM like Firecracker. Pick something with a real OS-level boundary.
3. Audit every place in your app where strings get evaluated as code. eval, Function constructors, dynamic require, vm.runInNewContext. Each one is a trust boundary you may not have realized you signed up for.
4. Get a manual audit. Automated scanners flag known CVEs. They do not catch the design choices that quietly turn an AI agent into a remote shell.

Sandboxes are hard. AI-generated code does not know that. Your auditor should.