A fresh critical sandbox escape landed in the popular Node.js library vm2 on October 1. On Node.js 24 and newer, a double-prefix trick lets untrusted code pull in node:test and break out to host shell commands. A proof of concept is public. Fixed release: 3.11.7.
If any microservice still evaluates untrusted JavaScript inside vm2, Friday’s job is a dependency bump — and a hard look at whether that sandbox should still exist at all.
A sandbox that trusts a single-stripped
node:prefix is not a sandbox. It is a suggestion. The 5-Minute Cyber BriefDon’t Miss the Policy Changes That Affect Security Decisions
Get the key CISA actions, new regulations, guidance, and risk shifts in a quick daily brief.
By subscribing you agree to our Privacy Policy.
Free. Weekday mornings. 5 minutes or less.
What happened
CVE-2026-92948 (GHSA-qhwx-74w5-xhxq) affects vm2 versions 3.9.6 through 3.11.6 when running on Node.js 24+. The library’s builtin blocking can be bypassed by double-prefixing a restricted module name (for example node:node:test). After a single prefix strip, the host resolves node:test. The test runner’s run() path can then pass attacker-controlled execArgv into a spawned host Node process — complete sandbox escape and host RCE. Industry scoring places it at CVSS 9.9. Fixed in vm2 3.11.7 with recursive prefix validation.
This is not the first escape class against vm2. Maintainers and researchers have repeatedly urged migration to stronger isolation (isolated-vm, containers, gVisor). Treat 3.11.7 as the emergency stop, not the long-term architecture.
Why it matters
Any SaaS feature that “safely” runs customer or plugin JavaScript inside vm2 on modern Node is one crafted payload away from host compromise. CI plugins, low-code expression engines, multi-tenant script runners, and internal tooling that still pin old vm2 are the usual blast radius.
What to do first
- Find vm2. Search lockfiles and images for
vm2on Node 24+ runtimes. - Upgrade now. Bump to vm2 ≥ 3.11.7 and redeploy.
- Harden allowlists. Remove wildcard
*andnode:testfrom NodeVM builtin allowlists even after the bump. - Plan the exit. Prefer isolated-vm or real container / gVisor boundaries for untrusted code. Do not bet the tenancy model on vm2 alone.
Forward this
If you own Node services that evaluate untrusted JS: vm2 on Node 24+ has a critical sandbox escape (CVE-2026-92948) with a public PoC. Please confirm every dependency is on 3.11.7+, that node:test is not allowlisted, and that we have a plan to leave vm2 for stronger isolation.
Details
- CVE / advisory: CVE-2026-92948 / GHSA-qhwx-74w5-xhxq
- Impact: Sandbox escape → host RCE via
node:teston Node.js 24+ - CVSS: 9.9 (industry reporting)
- Affected: vm2 3.9.6–3.11.6 on Node.js 24+
- Fixed: vm2 3.11.7
- Exploit status: Proof of concept available; not on KEV at publish time
Hunt / verify
- Confirm deployed
node_modules/vm2/package.jsonversion ≥ 3.11.7. - Review NodeVM configs for
builtin: ['*']or explicitnode:test. - Watch for unexpected child Node processes spawned from script-runner hosts.
Slack paste: vm2 CVE-2026-92948 sandbox escape on Node 24+ — bump to 3.11.7 now, strip node:test from allowlists, plan move off vm2.
Sources
Start your morning with the signal that matters.
Get the biggest cybersecurity developments, why they matter, and where to go deeper on CyberExperts.
By subscribing you agree to our Privacy Policy.
Free. Weekdays. Built for operators.