vm2 CVE-2026-92945

Requires vm2's threat model to be in play: the host application must deliberately execute untrusted JavaScript inside vm2. Beyond that, exploitation depends on a specific non-default configuration - a module allowlist must be enforced AND transitive loading disabled - and on the existence of an allowlisted package from which a relative require can reach a non-allowlisted package whose resolved path shares a leading string prefix with an allowlisted module. Limiting factors: PR:L means the attacker's code is already running inside the sandbox (not a fully external attacker), AC:H/AT:P reflect the required prefix-collision and non-automatable nature, and impact is confined to reaching an extra module (VC:L/VI:L, no availability or subsequent-system impact). It does not, by itself, grant host code execution.

This is a genuinely low-priority issue and the signals are consistent about it, unlike much of the vm2 lineage. The vendor CVSS 4.0 base score is only 2.3 with AV:N/AC:H/AT:P/PR:L/UI:N and impacts capped at VC:L/VI:L/VA:N and no subsequent-system impact (SC:N/SI:N/SA:N) - i.e. a low-impact, hard-to-reach, privilege-requiring, attack-requirement-gated weakness rather than a full sandbox escape. No EPSS score, no CISA KEV listing, and no public POC are present in the provided data, so the correct characterization is 'no public exploit identified at time of analysis.' The AC:H/AT:P combination reflects that exploitation is not automatable and depends on a specific precondition (an allowlisted package that shares a name prefix with a non-allowlisted target and from which a relative require can be performed) plus a non-default configuration (module allowlist enforced with transitive loading disabled). This is best understood as an incremental hardening fix to require-path validation, not an urgent, independently-actionable vulnerability. It is only meaningful within vm2's threat model (an application deliberately runs untrusted JavaScript inside vm2) and even then yields, on its own, only expanded module reachability - potentially a stepping stone toward the more severe escape/RCE issues fixed in the same 3.11.7 release, but not equivalent to them.

An application runs untrusted JavaScript in vm2 with a module allowlist and transitive loading disabled, assuming only the listed packages are reachable. The untrusted code, executing from within an allowlisted package, issues a relative require to a non-allowlisted package whose path shares a string prefix with an allowlisted one, and the raw-prefix check in isPathAllowedForModule wrongly approves it. No public POC or active exploitation is indicated in the provided data.