CVE-2026-92951 in vm2
Summary
by MITRE • 09/17/2026
vm2 before 3.11.7 contains an incorrect authorization vulnerability in the external package allowlist check that uses non-exact substring matching instead of full package-name boundary validation. Attackers can bypass the allowlist by requiring a colliding package name that contains an allowlisted package substring, causing vm2 to load and execute unauthorized host packages in the host context.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in versions of vm2 prior to 3.11.7 represents a critical flaw in the security model designed to isolate untrusted code execution environments from the host system. This specific issue stems from an incorrect authorization mechanism within the external package allowlist check, which relies on non-exact substring matching rather than rigorous full package-name boundary validation. In secure software design, particularly when dealing with sandboxed execution contexts like vm2, it is imperative that access controls strictly define permitted resources to prevent any form of escape or unauthorized interaction with the host environment. The implementation in these earlier versions failed to enforce strict boundaries for package names, allowing a broader set of inputs than intended by the security policy.
From a technical perspective, the core flaw lies in how the allowlist evaluates incoming requests for external modules. Instead of verifying that an input matches a specific allowed package name exactly or adheres to precise path delimiters and namespace structures, the system performs a simple substring search. This means that if a developer has explicitly whitelisted a safe library such as lodash, any request for a maliciously crafted module named something like my-lodash-backdoor will pass the validation check because it contains the string lodash. Consequently, the sandboxed environment proceeds to load and execute this unauthorized package within the host context, effectively bypassing the intended isolation barriers.
The operational impact of this vulnerability is severe, as it allows attackers to achieve arbitrary code execution on the server hosting the vm2 instance. By exploiting the substring matching weakness, an adversary can require a colliding package name that contains an allowlisted package substring. Once loaded, these unauthorized host packages operate with the same privileges and access rights as the legitimate application code. This leads to potential data exfiltration, complete compromise of the underlying system integrity, and further lateral movement within the network infrastructure depending on the permissions granted to the process running vm2. Such an escape from a sandbox is particularly dangerous because it undermines the fundamental assumption that untrusted user input cannot affect the host environment.
This vulnerability aligns with CWE-798: Use of Hard-coded Credentials or Incorrect Authorization, specifically falling under improper access control where insufficient validation allows unauthorized resource access. In terms of offensive security frameworks, this technique corresponds to ATT&CK T1059 Command and Scripting Interpreter via dynamic code execution, as the attacker leverages the sandbox's ability to load external modules to execute arbitrary logic outside its intended constraints. The failure to validate package boundaries is a classic example of how loose string matching can lead to significant security breaches in dependency management systems.
To mitigate this risk, organizations must immediately upgrade vm2 to version 3.11.7 or later, where the allowlist check has been corrected to perform exact package-name boundary validation rather than substring matching. This ensures that only explicitly defined packages are loaded and prevents colliding names from bypassing security controls. Additionally, developers should review their application dependencies for any usage of vm2 in production environments and ensure that all third-party libraries are kept up to date with the latest security patches. Implementing strict input validation policies and regularly auditing dependency trees can further reduce the attack surface associated with dynamic module loading mechanisms.