CVE-2026-92959 in vm2
Summary
by MITRE • 09/17/2026
vm2 before 3.11.8 does not fully enforce the allowAsync: false option in VM and NodeVM. While localPromise.prototype.then is replaced with a handler that throws 'Async not available', the sandbox's Promise static methods (Promise.resolve, Promise.all, Promise.race, Promise.any, and Promise.allSettled) still assimilate attacker-supplied thenables: native promise resolution performs PromiseResolveThenableJob and invokes the sandboxed code's then method in a microtask without passing through the patched then, so the async restriction is never applied. As a result, sandboxed script can schedule work that runs after VM.run() or NodeVM.run() has returned and outside the configured timeout, continuing to execute after the host believes execution is complete.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in versions of vm2 prior to 3.11.8 represents a significant bypass of sandboxing mechanisms designed to restrict asynchronous code execution within isolated JavaScript environments. The core issue stems from an incomplete enforcement of the allowAsync configuration option, which is intended to prevent scripts running inside the virtual machine or NodeVM instance from utilizing asynchronous operations that could lead to uncontrolled resource consumption or escape attempts. While the developers correctly patched the local Promise.prototype.then method by replacing it with a handler that throws an Async not available error, this fix was insufficient because it failed to address how native promise resolution interacts with sandboxed code through static methods on the global Promise object.
The technical flaw lies in the behavior of native promise resolution when handling thenables provided by attacker-supplied scripts. When functions such as Promise.resolve, Promise.all, Promise.race, Promise.any, or Promise.allSettled are invoked within the sandbox and passed a custom thenable object from untrusted code, the JavaScript engine performs a PromiseResolveThenableJob operation. This internal mechanism invokes the then method of the provided thenable directly in a microtask queue context. Crucially, this invocation bypasses the patched prototype handler that was intended to block asynchronous execution. Because the native resolution process calls the sandboxed then method without routing it through the security check logic, the restriction on async operations is effectively neutralized for these specific promise static methods.
The operational impact of this vulnerability allows a malicious actor executing code within the sandbox to schedule work that persists beyond the expected lifecycle of the execution context. Specifically, sandboxed scripts can create promises or thenables that trigger callbacks after VM.run() or NodeVM.run() has returned control to the host application. This means that asynchronous tasks continue to execute even when the host system believes the script has finished running and is no longer active. Such behavior defeats the purpose of execution timeouts and resource limits, potentially leading to denial-of-service conditions through infinite loops or unbounded memory consumption in background microtasks. Furthermore, this persistence can facilitate more complex attack vectors where state is maintained across what should be isolated execution boundaries, undermining the integrity of the sandboxing model.
From a classification perspective, this vulnerability aligns with CWE-749, which describes exposure to an unsafe API within a restricted context, as it involves improper restriction of operations for normal users rather than administrators or privileged users. It also relates to CWE-829, concerning inclusion of functionality from outside trusted control, given that the sandbox relies on external promise resolution mechanisms that are not fully sanitized. In terms of threat modeling and detection, this behavior corresponds to ATT&CK technique T1059.007, JavaScript execution, specifically highlighting how attackers can abuse legitimate scripting features like promises to evade security controls designed to limit script capabilities. The vulnerability underscores the complexity of securing dynamic code evaluation environments where native language constructs must be carefully wrapped or monitored to prevent bypasses through standard API interactions.
Mitigation strategies primarily involve upgrading to vm2 version 3.11.8 or later, where this specific bypass has been addressed by ensuring that all paths leading to asynchronous execution are properly intercepted and blocked according to the allowAsync setting. For environments unable to upgrade immediately, implementing additional layers of security such as strict Content Security Policies for any web-based interfaces interacting with these sandboxes can help limit exposure. Additionally, developers should avoid passing untrusted objects into native promise static methods unless absolutely necessary, or alternatively, wrap those static methods themselves in custom handlers that validate the origin and nature of thenables before allowing resolution to proceed. Regular auditing of sandbox configurations and continuous monitoring for anomalous background task execution patterns are also recommended defensive measures to detect potential exploitation attempts in real-time.