CVE-2026-44007 - vm2 NodeVM nesting sandbox escape

vm2 NodeVM allowed a host that configured nesting: true with require: false to accidentally expose vm2 inside the sandbox. Sandboxed code could then construct an inner NodeVM with attacker-chosen require settings and reach host OS command execution.

The maintainer fix rejects the specific dangerous construction, but the safer production posture is broader: do not run untrusted or tenant-supplied code with nesting: true, and do not treat vm2 as a sufficient isolation boundary for secrets, internal networks, build systems, or agent plugin execution.

When to use it

Use this recipe when a Node.js repository depends on vm2 or owns a runtime that executes user, tenant, plugin, notebook, workflow, or agent-generated JavaScript through NodeVM. It is especially important when nesting: true, custom require policies, or secret-bearing worker processes appear in the same codebase.

This recipe is for safe remediation and review. It should not be used to prove exposure by executing operating-system commands through a sandbox.

Inputs

  • Node package manifests, lockfiles, SBOMs, image metadata, deployment manifests, and generated dependency reports that may resolve vm2.
  • NodeVM construction sites, shared sandbox helpers, plugin/workflow runners, notebook services, tenant script engines, and test fixtures.
  • Configuration evidence for nesting, require, builtin/module allow-lists, async behavior, timeout/memory limits, and environment/file/network access.
  • Classification of script sources and callers: internal, admin, user, tenant, plugin, workflow, notebook, CI, or agent-generated.
  • Secret, workspace, and network authority available to each sandbox process, plus existing credential-rotation and container-hardening procedures.

Affected versions

Package Vulnerable versions Fixed versions
vm2 <3.11.1 3.11.1

Indicator-of-exposure

  • The repository depends on vm2 before 3.11.1.
  • Application code creates new NodeVM(...) for untrusted, user-supplied, tenant-supplied, plugin, notebook, workflow, or agent-generated JavaScript.
  • Any NodeVM configuration uses nesting: true, especially alongside require: false or a narrow require allow-list.
  • The sandboxed process can read environment variables, workspace files, source code, cloud credentials, package-manager tokens, internal services, sockets, or CI artifacts.

Quick checks:

rg -n "from ['\"]vm2|require\\(['\"]vm2['\"]\\)|new NodeVM|nesting\\s*:\\s*true|require\\s*:\\s*false|allowAsync|sandbox" .
npm ls vm2
pnpm why vm2
yarn why vm2

Remediation strategy

  • Upgrade vm2 to 3.11.1+ everywhere the repository controls dependencies, images, lockfiles, SBOMs, and build artifacts.
  • Remove nesting: true for untrusted code execution. If nested VM creation is a product requirement, treat it as host-code execution and require an explicit security exception.
  • Add policy tests that reject dangerous NodeVM configurations in shared sandbox helpers.
  • Run untrusted code in a stronger isolation boundary where possible, such as a locked-down container, VM, job sandbox, seccomp profile, network-denied worker, or disposable runtime identity.
  • Rotate credentials if untrusted code could have run in a vulnerable sandbox.

The prompt

You are remediating CVE-2026-44007 (vm2 NodeVM nesting sandbox escape). Produce
exactly one output:

- A reviewer-ready PR/change request that upgrades vm2, removes or blocks
  dangerous NodeVM nesting for untrusted code, adds policy tests, refreshes
  generated artifacts, and documents operator cleanup, or
- TRIAGE.md if this repository does not own an affected vm2 runtime or cannot
  make a safe patch.

## Rules

- Scope only CVE-2026-44007 and directly related vm2 sandbox hardening.
- Do not execute arbitrary OS commands through vm2 to prove exposure.
- Do not print, commit, or expose environment variables, package tokens, cloud
  credentials, CI secrets, source archives, tenant files, or subprocess output.
- Do not preserve `nesting: true` for untrusted code without an explicit
  documented product/security owner decision.
- Do not auto-merge.

## Steps

1. Inventory every Node.js app, worker, plugin runner, notebook service, CI
   helper, package workspace, container image, lockfile, SBOM, and deployment
   artifact controlled by this repository that references `vm2`.
2. Determine every resolved `vm2` version. A target is vulnerable if it resolves
   to `<3.11.1`.
3. Search for `new NodeVM`, `nesting: true`, `require: false`, custom require
   allow-lists, plugin execution, workflow scripting, agent tool execution,
   notebook/REPL features, and tenant-supplied JavaScript.
4. Classify every vm2 use:
   - trusted internal scripts only;
   - semi-trusted admin scripts;
   - untrusted user, tenant, plugin, notebook, workflow, or agent-generated
     code.
5. Upgrade `vm2` to `3.11.1+`. Regenerate lockfiles, package-manager metadata,
   image metadata, SBOMs, deployment render output, and dependency reports.
6. For untrusted or semi-trusted code, remove `nesting: true`. If nested VM
   creation is required, stop with `TRIAGE.md` unless the repo can move that
   execution to a stronger isolation boundary.
7. Add or update a central sandbox configuration helper that rejects dangerous
   combinations, including:
   - `nesting: true` with untrusted code;
   - `nesting: true` plus `require: false`;
   - `nesting: true` plus narrow builtin allow-lists that imply module
     isolation;
   - access to `child_process`, `fs`, network modules, package managers, or
     environment secrets for untrusted code.
8. Add safe tests that inspect configuration and denial behavior without
   running exploit commands.
9. Add a PR body section named `CVE-2026-44007 operator actions` that states:
   - vm2 versions before and after;
   - every NodeVM call site and whether it handles untrusted code;
   - whether `nesting: true` remains anywhere and who approved it;
   - whether stronger runtime isolation is required;
   - whether credentials, package tokens, or CI secrets should be rotated due
     to possible prior sandbox escape.
10. Run the relevant validation: package install, unit tests, sandbox policy
    tests, lint/typecheck, container build, SBOM refresh, dependency/security
    scans, and plugin/workflow execution tests available in this repository.
11. Use PR title:
    `fix(sec): remediate CVE-2026-44007 in vm2 NodeVM`.

## Stop conditions

- No affected vm2 runtime or deployable artifact is controlled by this repo.
- All controlled targets already resolve `vm2 >=3.11.1` and generated artifacts
  are current.
- The product intentionally runs untrusted code with `nesting: true`; document
  the owner decision needed and propose stronger isolation.
- Verifying exposure would require executing OS commands or exposing secrets.
- Validation fails for unrelated pre-existing reasons; document those failures
  instead of broadening scope.

Verification - what the reviewer looks for

  • No manifest, lockfile, image, SBOM, or deployment artifact resolves vm2 <3.11.1.
  • Untrusted code paths do not use NodeVM with nesting: true.
  • Shared sandbox helpers fail closed for dangerous configurations.
  • Tests prove policy rejection without running exploit commands.
  • Operator actions address credential rotation and stronger isolation where prior exposure was plausible.

Watch for

  • Transitive or vendored vm2 copies in plugin runners, templates, examples, or CI helper packages.
  • Comments that say require: false makes nested sandboxes safe.
  • Agent plugin systems where user-provided code runs near repository secrets, package tokens, or deployment credentials.
  • Upgrading vm2 while leaving generated containers or SBOMs stale.

Output contract

Return one of:

  • A reviewer-ready PR/change request that upgrades vm2 to 3.11.1+, removes or blocks unsafe NodeVM nesting for untrusted code, centralizes the sandbox policy, adds safe denial tests, refreshes generated artifacts, and documents operator cleanup.
  • TRIAGE.md when no controlled affected vm2 runtime exists, when all controlled deployable artifacts are already patched, or when product/security ownership must decide how to replace intentional untrusted nested VM use.

The output must identify every NodeVM call site, state whether nesting: true remains anywhere, name the owner-approved isolation boundary for untrusted code, list validation commands, and call out credential rotation where prior sandbox escape was plausible. Do not include OS-command exploit payloads, secrets, or sensitive sandbox output.

References