Eight Sandbox-Escape Flaws Hit vm2, Three Rated Max Severity — Patch to 3.11.4 Now (CVE-2026-47131)

vm2, a go-to building block for running other people's code inside a "safe cage," has been hit with eight vulnerabilities at once that let an attacker break out of the cage and take over the server. Patched versions are now available. Three of the eight carry the maximum international severity score of 10.0. vm2 is a library for isolating untrusted code, or code generated by AI, so it can run without harming the host, and it is downloaded more than 1.3 million times a week from npm (the public package registry).

All eight were disclosed on June 12, 2026, and all are fixed in vm2 3.11.4. The top-scoring CVE-2026-47131, CVE-2026-47137, CVE-2026-47140, and CVE-2026-47208 are "sandbox escapes" that let code inside the cage run arbitrary programs on the server itself. The remaining ones, CVE-2026-47210 (9.8), CVE-2026-47135 (8.7), CVE-2026-47139 (8.6), and CVE-2026-47209 (8.6), are holes that bypass the isolation wall or let attackers tamper with data on the host side.

The heaviest issue this time is not the depth of any single hole but the premise behind them all. vm2 is a library whose development has already ended, and the author himself has stated that no further safety can be guaranteed. In other words, updating to 3.11.4 is a stopgap that plugs these eight holes, but the real fix is to stop using vm2 and move to a different isolation method. There are no reports of these being exploited in the wild so far, but as discussed below, vm2 has seen a steady stream of vulnerabilities since the start of 2026, and the danger only piles up the longer it is left in place.

What vm2 Is, and Why It Concerns You

vm2 is a component that runs untrusted code inside an isolated environment called a "sandbox" within a JavaScript (the language that runs on the web and on servers) program. A sandbox is a closed area, like a sandpit where children play, in which nothing that happens spills out to affect the outside world (the server itself). It has been widely used for situations that mean "running someone else's code on your own server," such as evaluating formulas or scripts that external users submit, or executing plugins and templates.

The tricky part is that even if you never call vm2 directly, it is common for another component you have pulled in to use vm2 internally. This is called an "indirect dependency." Template processors, no-code tools, online code-execution environments, and config-file evaluation engines can all embed vm2, so even if you think "we don't use vm2," it is not unusual to find it running deep down once you trace the dependencies.

The group that suddenly grew larger in 2026 is the world of AI agents. A setup that runs code generated by a large language model on the spot is the textbook case of "safely running code you cannot fully trust," and implementations that use vm2 for that isolation are out in the wild. The security firm Kodem points out that in this configuration, there is a straight line running from prompt injection (a malicious instruction to the AI) all the way to a full takeover of the server. As the table below shows, the starting point is to check how this concerns you in your own role.

Conversely, if you only use vm2 to run trusted in-house code (and never pass it any external input), these eight issues are less likely to translate directly into an attack. The level of danger swings heavily on whether or not you are feeding vm2 code whose author you cannot vouch for.

An Overview of the Eight Vulnerabilities

All eight are holes in "the isolation wall called the sandbox." By nature, they split into those that reach all the way to running arbitrary programs on the server (a takeover) and those that slip a piece of the wall to allow communication or writes. The severity figures come from the "CVSS," an international common score that rates seriousness from 0 to 10. Let's get the big picture from the list first.

In every case, the precondition for attack is that "code the attacker prepared runs inside the sandbox." So if your design runs strings received from outside directly through vm2, an attacker can hit the hole through that input path without going through any login or other authentication. Four of the eight, the top-scoring ones, lead straight to a state where anything can be run on the host from inside the cage (a takeover).

Who Wants This Bug, and What Do They Walk Off With

The phrase "sandbox escape" is too technical to picture your own losses from, so let's look at what the maximum score of 10.0 really means from the attacker's side. vm2 is, by definition, "a place to run untrusted code," so having it broken is the same as having an entrance built in from the start through which malicious code can be sent.

The people who come after this are pranksters who throw fake assignments at grading sites and code-execution services, industrial spies trying to worm into an internal automation platform, scam groups who smooth-talk an AI agent into opening a back door, and access brokers who sell entry points into hijacked servers on the underground market. What they walk off with is the customer email addresses and passwords stored on the server, cloud credential keys, the contents of databases, API secret keys, and a foothold into the internal network. The instant a victim trips over CVE-2026-47131 or CVE-2026-47208 this time, the wall of the supposedly isolated cage disappears, and whatever command the attacker likes starts running directly on the server itself.

The distinctly 2026 kind of dread lies in the route through AI agents. In a design where the AI writes code from text the user enters and then runs it inside vm2, the attacker does not even need to write code directly. They put a crafted request into the chat box, get the AI to generate dangerous code, and the moment it runs in vm2 the escape is complete. What sets this decisively apart from a traditional sandbox escape is that, with no specialized coding knowledge, words alone can reach inside the server.

And the responsibility for the damage falls not on vm2's author but on the company that operates the service that embedded it. If customer personal data leaks, mandatory breach disclosure to regulators and affected users kicks in, and depending on the scale, damage claims and loss of trust pile on. The number CVSS 10.0 includes none of the cost of apologies, investigation, and compensation that follow a breach. With a fix now available, the dividing line is whether you can check your dependencies and act in time.

The Four That Lead Straight to Server Takeover (CVSS 10.0)

The four top-scoring issues are all "sandbox escapes" that let code inside the cage call programs on the host side. The mechanisms differ slightly, but what they share is that "the wall meant for isolation had just one spot left where a host-side feature leaked through."

CVE-2026-47131: Escaping by Stealing Host-Side Type Information

JavaScript has a mechanism for creating an error (a type error) that appears when a value is of a different kind than expected. CVE-2026-47131 works when code inside the cage cleverly provokes Node.js's own error-generation routine, obtaining a host-side component it should never be able to touch (a constructor for creating errors) and using it as a foothold to escape. The score is a perfect 10.0, and once it succeeds, arbitrary programs can be run on the host.

CVE-2026-47137: A Past Fix Voided by a Missing Option

CVE-2026-47137 is a hole that came back to life because the fix for an old vulnerability supposedly patched in 2023 (CVE-2023-37903) was incomplete. The fix at the time strictly checked whether a certain setting was "written exactly as false." But because the check can be slipped simply by not specifying that setting at all, an escape succeeds by omitting a single option. It is a textbook example of how hard fixes are, where a hole patched once reopens through a slight gap in the conditions.

CVE-2026-47140: Gaps in the Blocklist of Dangerous Features

vm2 seals off dangerous features that must not be touched from inside the sandbox using a "blocklist." CVE-2026-47140 is a hole where the process-control feature (process) and the debugging feature (inspector) had fallen off that list, letting code reach them from inside the cage. A scheme that manages the entrances to be sealed as a list carries the weakness that a single omission becomes an escape route.

CVE-2026-47208: Abusing the Promise Mechanism to Run Commands

CVE-2026-47208 is a hole that abuses the behavior of "Promise," JavaScript's mechanism for handling asynchronous processing, to break the cage and run arbitrary commands on the server. Promise has a flexible device that lets you swap out the type that wraps a result, and when that is exploited, a hand reaches across the isolation boundary to the host side. This one, too, is a perfect 10.0.

The Remaining Four That Bypass the Wall (CVSS 9.8 to 8.6)

The remaining four do not reach an instant takeover, but they slip through a part of the isolation wall to allow outbound communication or writes to host data. Even if they look a notch lighter on their own, combined with the other holes they become a foothold for widening the damage.

CVE-2026-47210: Escape via a New WebAssembly Feature

CVE-2026-47210 (9.8) is an escape leading to arbitrary code execution on the server itself when asynchronous processing is enabled and the new WebAssembly (a mechanism for running code at high speed in browsers and on servers) integration feature "JSPI" is available in that environment. Because it requires a specific runtime environment to fire, it stops just short of a perfect score, at 9.8.

CVE-2026-47135: Missing Special Symbols That Should Be Blocked

CVE-2026-47135 (8.7) is a hole that remained because, among the special symbols that straddle the boundary between host and cage, only 2 of the 9 that should be blocked were sealed. Starting from the leftover symbols, a chain that hijacks host-side processing falls into place. The attack is rated somewhat difficult, but if it succeeds it leads to data leakage or tampering with processing.

CVE-2026-47139: Unauthorized Outbound Traffic via a Hidden-Name Network Module

CVE-2026-47139 (8.6) is a hole where, even with a setting that forbids external communication, internal-use networking modules with an underscore prefix (such as _http_client) had been left off the block list, letting code inside the cage send out or listen for traffic. It becomes a foothold for using the server as a stepping stone to probe the internal network, a so-called pivot.

CVE-2026-47209: Tampering With Host Data Without Checking the Write Destination

CVE-2026-47209 (8.6) is a hole where the bridging routine that passes data between the cage and the host writes a value into a host-side object without properly checking the write destination. It does not read information, but because it can rewrite host-side data, it risks being used to tamper with settings or prepare another attack.

The Real Problem Is That vm2 Has Already Ended Development

Fixes for the eight issues are out, but what matters most is not the individual holes; it is the state of the vm2 component itself. The vm2 repository carries a clear notice from the author: "This project is discontinued. Please stop using it as a secure sandbox." This is the author's judgment that, on the premise that similar escapes will keep being found, maintenance can no longer keep up.

In fact, escape-type vulnerabilities in vm2 have been disclosed back to back since the start of 2026. In May, a fix on the order of a dozen-plus issues was made, and these eight are a continuation of that wave. Security researchers have been systematically digging into vm2's escape techniques, and new bypasses keep turning up one after another. At the root is the difficulty of the design goal of "completely separating the host and the isolated area within the same program." Because JavaScript's language machinery is so rich, there are countless thin paths leading to the host side, and even when you seal one, another tends to remain.

For that reason, for the purpose of running untrusted code, the current recommendation is to move to a stronger isolation method rather than a library approach like vm2. Concrete options include isolated-vm, which runs fully separated as a distinct process, containers (a scheme that partitions at the OS level, such as Docker), and dedicated sandbox platforms. It is safest to treat this update as a stopgap to buy time, and to advance a migration plan in parallel. The more established a component is, the easier it is to put off replacement because "it's working," but continuing to use a component whose development has stopped on the front line of security becomes a war of attrition in which you reactively patch each hole as it opens.

Is Your App Affected? (How to Check)

You can check the version currently installed by typing npm ls vm2 in your project folder. It lists which version is installed, including indirect dependencies. Match your number against the table below. The fixed version is 3.11.4.

If an old vm2 is present through an indirect dependency, you may also need to update the parent component that calls it. Knowing in advance "which component is bringing vm2 along" via npm ls vm2 makes the work easier to plan. If you want to inspect your dependencies all at once, running them once through an OSS vulnerability-checking tool that surfaces dangerous versions by simple paste-in lets you catch the "turns out an old vm2 was lurking deep down" case early.

What to Do Right Now

The most reliable immediate measure is to update vm2 to 3.11.4. If you depend on it directly, you can upgrade with npm install vm2@3.11.4. For an indirect dependency, confirm the match with npm audit or a vulnerability database, then either update the parent component or force a safe version using npm's override feature (overrides).

On top of that, if you are running untrusted code in vm2, you should begin rethinking the isolation method itself in parallel with the update. Identify the spots that pass externally received strings straight into vm2, and steer the design toward isolating them in a separate process or container. For a setup that lets AI generate and run code, it is realistic to combine layered defenses: insert a check that rejects dangerous instructions before the generated code runs, and physically cut off the execution environment's reach to the network and the file system. No real-world attacks have been confirmed so far, but because the escape techniques are already public and systematized, the locations of the holes become even easier to pin down after a fix is released. Putting it off simply accumulates the danger.

Why "Components That Run Other People's Code" Keep Getting Targeted

A component like vm2 sits, by its very purpose, at the place where "untrusted things are accepted." That is exactly why attackers' aim concentrates on it, and even when one hole is sealed it gets probed again from another angle, in an endless back-and-forth. The more popular a staple is, the more it keeps getting targeted from both directions, holes in the code itself and attacks on the distribution channel, a pattern that has repeated with other npm packages too.

Recently as well, a vulnerability that leaks credentials was found in axios, the go-to for HTTP communication, and on another occasion an incident occurred in which a poisoned version of a popular library cascaded into a VS Code extension. On the distribution side too, the move where npm shifted toward stopping automatic execution of dependency packages is part of the same continuum.

That is precisely why you need the mindset of continuously inspecting which version each component you pull in from outside is, whether it harbors known holes, and "whether it is even still maintained in the first place." For a component whose development has ended, like vm2, no amount of updating does anything but leave the next hole waiting. Without forgetting that the sheer number of users translates directly into the breadth of the damage, the lesson these eight issues press home most strongly is to not put off the decision to replace something precisely because it is a staple.

References

• ▸ vm2 - Release notes (v3.11.4 / 8 fixes)
• ▸ NVD - CVE-2026-47131 (CVSS 10.0 / sandbox escape)
• ▸ NVD - CVE-2026-47137 (CVSS 10.0)
• ▸ NVD - CVE-2026-47140 (CVSS 10.0)
• ▸ NVD - CVE-2026-47208 (CVSS 10.0 / command execution)
• ▸ NVD - CVE-2026-47210 (CVSS 9.8 / via WebAssembly JSPI)
• ▸ NVD - CVE-2026-47135 (CVSS 8.7)
• ▸ NVD - CVE-2026-47139 (CVSS 8.6 / outbound-traffic block bypass)
• ▸ NVD - CVE-2026-47209 (CVSS 8.6 / host data tampering)
• ▸ vm2 official security advisories (GitHub)
• ▸ Kodem - vm2 vulnerabilities and host takeover via AI agents
• ▸ Semgrep - A walkthrough of vm2 sandbox escape techniques
• ▸ npm - vm2 package page