A Prefix Check Could Let JavaScript Escape vm2
A sandbox can approve one module yet accidentally authorise its neighbour. vm2’s 8 September advisory describes a path-prefix error that lets guest JavaScript reach code running in the host process. This previously missed disclosure was revalidated after NVD indexed it on 27 September.
The host-escape advisory covers CVE-2026-100721 in NodeVM deployments using a custom external resolver and host context. A readable, prefix-sharing sibling file must exist. Both this issue and the companion availability flaw affect releases through 3.12.1 and are fixed in 3.12.2.
A matching prefix is not the same directory
In the published reproduction, loading the approved module enables a later request for a sibling whose path starts with the same characters. The host loader runs that file’s top-level code before wrapping its exports. The advisory contains a public test harness; it does not report malicious exploitation.
The companion issue can stop the service
The second advisory identifies CVE-2026-100722. It needs an application-exposed, constructable host function that returns a rejected native Promise. Invoking it as a constructor leaves the rejection unhandled; under Node.js’s strict policy, the host process can terminate. That is a denial-of-service path, separate from the resolver escape.
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.
Review 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
- Upgrade to 3.12.2 or later. Use the fixed release as the minimum version target.
- Inventory embedded use. Search direct and transitive dependencies, internal platforms, workflow products and plug-in systems for vm2.
- Review resolver settings. Prioritise deployments using a custom resolver, external modules and host context.
- 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. Repeated uncaught Promise rejections around guest execution may be relevant to the denial-of-service path, although they are not proof of 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: a secure module boundary does not establish that the application has adequate availability controls.
BlackTree’s Avast sandbox analysis concerns a different product and privilege boundary, but offers related context for assessing what a sandbox failure exposes.
Sources
- vm2 host escape advisory, published 8 September 2026 at 16:26:58 UTC, 18:26:58 CEST. No separate update time was exposed on the public page.
- vm2 host-process termination advisory, published 8 September 2026 at 16:26:08 UTC, 18:26:08 CEST. No separate update time was exposed on the public page.
- vm2 3.12.2 release, published 8 September 2026 at 16:22:38 UTC, 18:22:38 CEST.
- NVD host escape record and NVD denial-of-service record, published 27 September 2026 at 02:17 UTC, 04:17 CEST. This delayed indexing is why the older primary advisories re-entered the discovery window.
