CVE-2023-32314: Sandbox escape in vm2

In May 2023, security researchers disclosed CVE-2023-32314, a critical sandbox escape vulnerability in vm2, a widely used Node.js library that claims to let developers execute untrusted JavaScript inside a restricted, isolated context. The flaw allowed an attacker who could get arbitrary code evaluated inside a vm2 sandbox to break out of that sandbox entirely and execute commands on the host system with the full privileges of the Node.js process — turning a "safe" code execution feature into a remote code execution primitive. Given that vm2 was downloaded tens of millions of times per month and embedded in CI/CD tools, code-execution playgrounds, bots, linters, and low-code platforms, the blast radius of this bug was significant.

This was not vm2's only sandbox escape that year — it was one of a cluster of critical vulnerabilities disclosed against the library in 2023 that ultimately led its maintainers to deprecate the project entirely. Understanding CVE-2023-32314 is also a useful case study in why "sandboxing untrusted code in the same process" is an inherently fragile security boundary, and why supply-chain visibility into which of your dependencies rely on such sandboxes matters.

What vm2 Does and Why This Bug Mattered

vm2 wrapped Node.js's built-in vm module — which Node's own documentation explicitly warns is not a security mechanism — and added extra isolation logic (custom Proxy-based context handling, patched globals, and contextified objects) to make it safe to run code from plugins, user scripts, or third-party extensions. Projects used it to build things like Discord bots with custom scripting, serverless code-execution services, CMS plugin systems, and internal tooling that needed to evaluate user-supplied expressions.

CVE-2023-32314 stemmed from the way vm2 handled the JavaScript Proxy specification when contextifying objects between the sandbox and the host realm. According to the public advisory and proof-of-concept published by the researcher who found it, the flaw let an attacker trigger the unexpected creation of a host-realm object from inside the sandbox. Because that object was not properly contextified, it retained a reference back to the real, unsandboxed Function constructor. From there, an attacker-controlled string could be compiled and executed as native host code — a textbook sandbox-to-RCE escape, achievable with a single self-contained snippet of JavaScript passed into vm.run() or equivalent sandbox entry points.

Affected Versions and Components

• Package: vm2 (npm)
• Affected versions: all versions up to and including 3.9.17
• Fixed version: 3.9.18
• Attack surface: any application that passes untrusted or semi-trusted JavaScript into a vm2 VM or NodeVM instance for evaluation
• Researcher credit: Takeshi Kaneko (@arkark) of GMO Cybersecurity, Ierae, Inc.

There were no supported workarounds for this issue short of upgrading. Because the vulnerable code path was in vm2's core contextification logic rather than an optional feature, disabling specific sandbox options did not reliably mitigate exploitation — the only durable fix was moving to the patched release.

It's also worth noting that vm2 shipped as a transitive dependency in a number of downstream tools, so applications that never called vm2 directly could still have been exposed through a plugin system, testing framework, or automation tool that pulled it in under the hood. This is a recurring theme in supply-chain risk: the vulnerable component is rarely the one your team wrote or even chose directly.

Severity: CVSS, EPSS, and KEV Context

CVE-2023-32314 was rated Critical, with NVD publishing a CVSS v3.1 base score of 10.0 (vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H) — the maximum possible score, reflecting a network-exploitable flaw requiring no privileges or user interaction, a scope change from the sandboxed context to the host, and complete loss of confidentiality, integrity, and availability. (Some vendor feeds list a 9.8 score using an unchanged-scope vector; the discrepancy comes down to how different scanners modeled the sandbox-to-host scope change, but every major source agrees the practical severity is critical.)

At time of writing, we are not aware of CVE-2023-32314 appearing on CISA's Known Exploited Vulnerabilities (KEV) catalog, and we don't have a verified, current EPSS score to cite here — treat any specific EPSS percentage you see elsewhere with caution unless it's pulled live from FIRST.org. That said, the combination of a public proof-of-concept, a trivial exploitation path, and a library embedded deep in JavaScript tooling made this the kind of finding that security teams should treat as high-priority regardless of whether it's formally flagged as "exploited in the wild" — sandbox escapes with published PoCs tend to get weaponized quickly once attackers understand the pattern.

Timeline

• Early-to-mid 2023: vm2 sandbox escapes begin surfacing in quick succession, including CVE-2023-29017, CVE-2023-29199, and CVE-2023-30547 — each a variation on the same underlying theme of incomplete isolation between the sandbox realm and the host realm.
• May 2023: CVE-2023-32314 is disclosed and published, describing the Proxy-specification host-object-creation flaw. A working proof-of-concept exploit is released alongside the advisory.
• Patch released: vm2 3.9.18 ships with a fix for the issue.
• Following months: Additional sandbox escapes are reported against vm2 (including CVE-2023-37466 and CVE-2023-37903), reinforcing that the underlying architecture — sandboxing untrusted code in-process using Proxies and monkey-patched globals — was fundamentally difficult to secure comprehensively.
• July 2023: vm2's maintainers formally deprecate the project, stating that it contains critical security issues and should not be used in production, and pointing users toward isolated-vm, which relies on genuine V8 isolates (separate heaps, no shared prototype chain) rather than same-process trickery.

The pattern here — a critical fix followed by yet another critical sandbox escape a few months later — is the real lesson of CVE-2023-32314. A single patched CVE didn't make vm2 safe; the architecture itself kept producing new escape primitives until the maintainers concluded the approach couldn't be hardened further.

Remediation Steps

1. Identify usage. Run npm ls vm2 (or your package manager's equivalent) across all services and confirm whether it's a direct or transitive dependency. Check plugin systems, bots, notebook/playground features, and CI tooling specifically — these are common hiding spots for vm2.
2. Upgrade immediately if you're on 3.9.17 or earlier. Move to 3.9.18 to close CVE-2023-32314 specifically.
3. Don't stop at the patch. Given vm2's subsequent history of further sandbox escapes and its eventual deprecation, treat any remaining use of vm2 as a standing risk rather than a resolved one. Plan a migration off the library entirely.
4. Migrate to a real isolation boundary. For genuine untrusted-code execution, prefer isolated-vm (true V8 isolates), a separate OS process with tightly scoped permissions, a container/microVM (e.g., gVisor, Firecracker), or a WebAssembly-based sandbox — mechanisms that don't rely on JavaScript-level trickery to separate "sandboxed" from "host" code.
5. Defense in depth. Regardless of which sandbox technology you choose, run it with least-privilege OS permissions, no filesystem or network access unless explicitly required, and resource limits (CPU, memory, execution time) so that even a successful escape has a smaller blast radius.
6. Audit historical exposure. If vm2 was in production before you upgraded, review logs for anomalous script evaluations, unexpected child processes spawned from your Node.js runtime, or outbound connections initiated from services that shouldn't be making them.

How Safeguard Helps

CVE-2023-32314 is a good illustration of why point-in-time vulnerability scanning isn't enough for software supply chain risk — the danger here wasn't just "one CVE," it was a library with a pattern of critical findings that eventually forced a full architectural rethink by its own maintainers.

Safeguard is built to catch exactly this kind of risk before it reaches production:

• Continuous dependency inventory that surfaces both direct and transitive uses of packages like vm2, so security teams aren't relying on developers to remember every plugin system or automation script that pulled it in.
• Real-time vulnerability intelligence that flags newly disclosed CVEs against your actual dependency graph — including CVSS context and whether a public exploit or PoC exists — so critical issues like CVE-2023-32314 surface the day they're published, not during the next quarterly audit.
• Risk-pattern detection that looks beyond a single CVE ID to highlight components with a history of repeated critical findings, the kind of signal that would have flagged vm2 as a candidate for proactive migration well before its final deprecation.
• Remediation workflows that generate actionable upgrade paths and track them to closure, so "we found it" turns into "we fixed it" without falling through the cracks between security and engineering.
• SBOM-driven attestation so that when a vulnerability like this hits the news, you can answer "are we affected, and where?" in minutes rather than days of manually grepping package-lock.json files across every repo.

Sandbox escapes like CVE-2023-32314 are a reminder that isolation boundaries are only as strong as their implementation — and that supply chain security means tracking not just individual CVEs, but the trajectory of the components your software depends on.