vm2 NodeVM Nesting Guard Bypass Enables Host RCE via Array-Shaped require Option (CVE-2026-92935)

A newly published GitHub Security Advisory (GHSA-8hr7-r645-pc6w, CVE-2026-92935) describes a sandbox-escape vulnerability in vm2's NodeVM component, rated CVSS 9.0 with a public proof-of-concept already available.

What was reported

According to the advisory, NodeVM computes an internal flag, hasRealRequireConfig, using a check equivalent to typeof requireOpts === 'object' && requireOpts !== null. Because JavaScript arrays pass this check, configuring NodeVM with {nesting: true, require: []} causes the guard meant to block nesting without an explicit require configuration to fail open. The array is then destructured by makeResolverFromLegacyOptions() into undefined option fields, and the resulting resolver is merged with a nesting override that exposes the host's vm2 module. Per the advisory's PoC, code running inside such an outer sandbox can require('vm2'), construct its own inner NodeVM with an attacker-chosen builtin allowlist (e.g. child_process), and execute arbitrary commands with the privileges of the host Node.js process. The advisory also notes this is distinct from the previously reported GHSA-m4wx-m65x-ghrr, which covers the same nesting primitive but not the array-shaped require bypass, and which reportedly misidentified 3.11.4 as patched.

Why it matters

Any application that embeds vm2's NodeVM to sandbox untrusted JavaScript — and that enables nesting with a require option that happens to be (or defaults to) an array — is exposed to full host command execution for any code the sandbox is asked to run. Given vm2's long history as a sandboxing library for plugin systems, bots, and code-execution services, exploitation could allow an attacker-controlled script to read secrets, modify files, or reach the internal network from what was assumed to be an isolated environment. The advisory states exploitation is limited to downstream applications that explicitly enable nesting and pass a malformed array as require, so exposure depends on specific host configuration rather than being universal to all vm2 users.

What defenders should do now

• Inventory services using vm2's NodeVM and check whether nesting is enabled and what shape is passed for require — specifically whether it could ever be an array (including via defaults or misconfiguration) rather than a well-formed options object.
• As an immediate mitigation, disable nesting entirely for any NodeVM instance that executes untrusted or semi-trusted code unless it is strictly required.
• Where nesting is required, ensure require is always passed as a proper configuration object and add validation/logging around how that option is constructed, since the root cause here is a type-confusion gap in the host's own input validation.
• For detection and hunting, consider monitoring for unexpected child-process spawning (e.g. execSync/exec calls) originating from Node.js processes that host sandboxing libraries, and review application logs for anomalous module-resolution or require('vm2') calls occurring from within sandboxed execution contexts.
• Track upstream guidance closely — vm2 has an established history of sandbox-escape findings, so confirm whether a patched release or official mitigation is issued and plan to apply it promptly.

This is developing, same-day intelligence based solely on the GitHub Security Advisory; details on affected version ranges and an official fix were not confirmed in the source at time of writing. For the full technical write-up and proof-of-concept, see the original advisory: GHSA-8hr7-r645-pc6w.