CVE-2026-26332 is a critical sandbox escape (CVSS 9.8) in vm2, the npm package that runs untrusted JavaScript in a Node.js sandbox. Through SuppressedError, code inside the sandbox can break out and run arbitrary code on the host. Versions up to 3.10.4 are affected. Upgrade vm2 to 3.11.0.
What's affected
The vm2 project advisory (GHSA-55hx-c926-fr95) lists affected versions as 3.10.4 and earlier and the patched version as 3.11.0. The NVD record agrees: versions before 3.11.0 are affected and 3.11.0 contains the fix.
The advisory text was written against vm2 3.10.4 on Node.js 24.13.0. It does not say whether the other Node.js versions behave differently, so do not assume an older runtime protects you. Check the advisory for updates.
The flaw affects anything that depends on vm2, directly or through another package. That is the part teams often miss: you may use vm2 only because a library you installed does.
How to check if you're exposed
List every place vm2 appears in your dependency tree. In an npm project:
npm ls vm2
npm why vm2
For pnpm and Yarn:
pnpm why vm2
yarn why vm2
Run these in every repository and in built container images, not only on your laptop. A lockfile search gives a quick first pass:
grep -n '"node_modules/vm2"' package-lock.json
If the version is 3.10.4 or lower, you are in range. The next question is whether your code ever passes untrusted input to vm2. A package that is installed but never calls the sandbox is a much lower risk than a service that runs customer supplied scripts through it. Reachability analysis answers that question for you by checking whether the vulnerable code can actually be called.
You can also run the free in browser dependency scan to see whether vm2 shows up in a manifest.
What to do now
- Upgrade vm2 to 3.11.0 or later. For a direct dependency, run
npm install vm2@3.11.0, and commit the lockfile. - For an indirect dependency, check whether the parent package has a release that updates vm2. If not, use your package manager's override feature to force 3.11.0, then run your tests.
- Rebuild and redeploy container images so the new version is in production, not only in source.
- If you run user supplied code, do not rely on a language level sandbox alone. Add isolation at the operating system level: separate process or container, no network access, tight memory and time limits, and a user with no secrets.
- Review logs and outbound connections from services that run sandboxed code for activity you cannot explain.
- Add vm2 to the list of packages that trigger an alert when a new advisory appears.
Why it matters
The record lists CWE-94, improper control of code generation (code injection), CWE-693, protection mechanism failure, and CWE-653, improper isolation or compartmentalization. Put plainly, the sandbox is a wall, and this bug is a way through it. The advisory says SuppressedError, a JavaScript error type used when cleanup code fails, lets code inside the sandbox reach objects from outside it and run arbitrary code.
The CVSS vector, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, scores network reach, low complexity and no login. That fits the typical use of vm2: a service that accepts code from users and runs it. If your product does that, the sandbox is the security boundary, and a break means the attacker is in your process.
The record is not on the CISA Known Exploited Vulnerabilities list, and the advisory does not say it has been exploited. The advisory does include a short proof of concept. This post does not repeat it.
Sandboxes written inside the language they sandbox have a hard job. New language features and built in error types create objects that the sandbox must wrap, and each addition can open a gap. That is why a fixed version helps today, and why defense in depth helps over the long run.
Red Hat also tracks this CVE, so check whether vendor software you run bundles vm2, and ask your suppliers if you are not sure.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Which vm2 version fixes CVE-2026-26332?
Version 3.11.0, according to the project advisory. Versions up to 3.10.4 are affected.
I only use vm2 through another package. Am I affected?
Possibly. If the package passes untrusted code to vm2, yes. Find out with npm why vm2, then check whether that code path is reachable.
Is a sandbox enough to run untrusted code?
Treat it as one layer. Add process or container isolation, no network and strict limits, so a sandbox bug does not hand over the host.
Sources
- vm2 security advisory GHSA-55hx-c926-fr95
- vm2 release v3.11.0
- Red Hat CVE page
- NVD record for CVE-2026-26332
Last reviewed: 19 October 2026.
