vm2 CVE-2026-92951

Requires that the host application (a) uses vm2 (before 3.11.7) to execute untrusted or attacker-influenced JavaScript, and (b) relies on vm2's external package allowlist (the require.external.modules / custom-resolver allowlist feature) as a trust boundary. The attacker must be able to introduce or reference a colliding package name that contains an allowlisted package name as a substring so the non-exact substring match approves it, and that colliding package must be resolvable/loadable in the host environment. Limiting factors: exploitation is meaningless if the app does not run untrusted code in vm2 or does not use the allowlist; the CVSS PR:L reflects that the attacker must already be able to run code inside the sandbox, and vm2 being deprecated bounds the realistic install base.

This is a genuine high-severity issue WITHIN the vm2 threat model, not merely a high-CVSS-but-low-impact finding. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N, all impact metrics High including subsequent-system SC:H/SI:H/SA:H) scores 9.4 and describes a sandbox-escape-class flaw: bypassing the external package allowlist lets sandboxed code load and execute unauthorized host packages in the host context, which is effectively arbitrary code execution on the host. I broadly AGREE with a critical rating but read the PR:L honestly - the 'privilege' here is the ability to run code inside the vm2 sandbox, which IS the entire premise of vm2's use, so operationally this behaves closer to unauthenticated-from-the-sandbox. Signals are CONFLICTING/INCOMPLETE in one direction only: there is NO EPSS score, NO CISA KEV listing, and NO explicit public exploit code identified at time of analysis, so despite the near-maximal CVSS this is not evidenced as widespread active exploitation. The dominant limiter is contextual: risk is real ONLY where an application (a) uses vm2 to run untrusted/attacker-influenced JavaScript AND (b) relies on the external package allowlist as a security boundary. vm2 is also deprecated (maintenance stopped ~3.9.19), so the '3.11.7' fix version does not cleanly match the real vm2 release history - treat the exact affected/fixed boundaries as needing vendor/advisory verification.

An application uses vm2 to execute untrusted user-supplied JavaScript and permits only a curated allowlist of external npm packages (e.g. 'lodash'). The attacker publishes or supplies a colliding package name whose string contains an allowlisted substring, and calls require() on it; vm2's non-exact substring match approves it, loading and executing the attacker-controlled package in the host context for full host code execution. No public exploit code is identified at time of analysis, but the advisory (GHSA-c48m-32m9-vx93) describes the mechanism concretely.