A Prefix Check Could Let JavaScript Escape vm2
CVE-2026-100721 requires custom resolution for external modules in NodeVM’s host context and a readable sibling sharing the permitted prefix. Guest code loads an approved module, then its neighbour. Module initialisation executes using the host’s privileges before export wrapping. The first advisory publishes test code without alleging attacks.
The companion flaw can stop the service
CVE-2026-100722 instead requires an application to expose a host function that supports construction and yields a native Promise in a rejected state. Calling it as a constructor leaves the failure unhandled; Node.js’s strict policy can end the application process. The second advisory describes availability loss, not a resolver bypass.
The advisory headers list releases through 3.12.1 as affected; their body text describes earlier tests, not a delivered fix. The 3.12.2 release notes explicitly name both corrections. NVD indexed these older disclosures on 27 September.
Check the application that embeds the sandbox
Start with an inventory of the services that execute other people’s expressions, scripts or plug-ins. Record the actual dependency version and configuration for each service. A dependency scanner can identify a package, but it cannot by itself establish which host functions the application exposes.
Apply general least-privilege guidance when reviewing the isolation boundary as an application decision. List the files, credentials and network destinations available to the execution process. Then test whether the service still works with less authority. Keeping a low-privilege guest inside a highly privileged process concentrates the consequences of a boundary failure.
Who needs to act
- Deploy the fixed minimum or newer. Apply the release identified above to the actual execution workers. For a bundled copy, use its product vendor’s supported update; an upstream package fix does not establish a product fix.
- Inventory embedded use. Search direct and transitive dependencies, internal platforms, workflow products and plug-in systems for vm2.
- Review resolver settings. Prioritise the module-loading configuration described above.
- Limit host capabilities. Do not expose powerful host functions merely because the guest code is expected to be sandboxed.
- Contain the process. Run untrusted evaluation in a separate, least-privileged operating-system process or container with restricted network and filesystem access.
- Check crash telemetry. Investigate repeated uncaught Promise rejections around guest execution. Such errors alone do not prove exploitation.
During rollout, use synthetic workloads to check both expected module access and denied access. Also verify how the surrounding service recovers from a worker crash. These are separate acceptance criteria: module isolation cannot guarantee availability.
BlackTree’s Avast sandbox analysis concerns a different product and privilege boundary, but offers related context for assessing what a sandbox failure exposes.
Sources
- Resolver advisory linked above, published 2026-09-08 16:26:58 UTC. No separate update time was exposed on the public page.
- Process-termination advisory linked above, published 2026-09-08 16:26:08 UTC. No separate update time was exposed on the public page.
- Release notes linked above, published 2026-09-08 16:22:38 UTC.
- Host escape index and Crash index, published 2026-09-27 02:17 UTC.
- General mitigations: least-privilege guidance linked above.
