CVE-2026-93604 in vm2
Summary
by MITRE • 09/18/2026
vm2 through 3.12.0 exposes Node.js's crypto.setFips() function to untrusted guest code when an embedder explicitly allowlists the crypto builtin for a NodeVM (require.builtin: ['crypto']). The builtin sanitizer (sanitizeCryptoModule in lib/builtin.js) replaces crypto.setEngine but leaves crypto.setFips callable, and the readonly wrapper used to expose the host module does not localize side effects of forwarded host functions. Guest code can therefore call crypto.setFips() to change the FIPS mode of the entire host process; the modified mode is subsequently observed by trusted host code (crypto.getFips() changed from 0 to 1 in the reported test), crossing the NodeVM isolation boundary. Fixed in vm2 3.12.1.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability identified in versions of vm2 up through 3.12.0 represents a critical failure in process-level isolation, specifically concerning the handling of cryptographic configuration functions when specific built-in modules are exposed to untrusted guest code. The NodeVM sandbox is designed to provide an isolated execution environment for running potentially malicious or untrusted JavaScript within a host application. However, when an embedder explicitly configures the VM to allowlist the crypto builtin module via the require.builtin option set to include 'crypto', the sanitization logic fails to adequately restrict access to certain sensitive functions. The internal sanitizer function responsible for cleaning up the crypto module correctly intercepts and replaces some methods like setEngine but erroneously leaves the setFips method callable by guest code. This oversight allows untrusted scripts to invoke host-level configuration changes that should be restricted to trusted context, thereby breaching the fundamental security boundary of the sandbox.
From a technical perspective, this flaw stems from an incomplete implementation of the module wrapper logic. The readonly wrapper used to expose the host's crypto module to the guest environment does not properly localize side effects associated with forwarded host functions. Specifically, when guest code calls crypto.setFips(), it directly modifies the FIPS mode state of the entire Node.js process rather than a sandboxed instance. This means that any subsequent operations performed by trusted host code using standard cryptographic APIs will operate under the modified security policy established by the untrusted guest. In practical terms, this allows an attacker to force the application into or out of Federal Information Processing Standards compliance mode without authorization, potentially disrupting secure communication channels or causing unexpected behavior in systems relying on strict FIPS validation for regulatory or operational reasons.
The operational impact of this vulnerability is severe due to its cross-boundary nature and potential for denial of service or configuration manipulation. By altering the global FIPS state, an attacker can effectively disable cryptographic protections that rely on specific algorithm restrictions mandated by FIPS mode, such as disabling weak ciphers or enforcing strict key lengths. This could lead to a degradation in security posture where sensitive data is processed using algorithms deemed insufficient for compliance requirements. Furthermore, if the application relies on the assumption that crypto settings remain constant during execution, this unexpected state change can cause logic errors, connection failures, or crashes when trusted code attempts to perform operations incompatible with the newly enforced FIPS constraints. The ability of guest code to observe these changes via functions like crypto.getFips confirms that the isolation boundary is completely compromised regarding configuration integrity.
This issue aligns closely with CWE-250, which describes execution without protection from incorrect assumptions about another component's actions, as well as CWE-693, Protection Mechanism Failure, where a security mechanism fails to prevent unauthorized access or modification of system state. In the context of the MITRE ATT&CK framework, this vulnerability facilitates lateral movement and privilege escalation within the application layer by allowing an untrusted script to manipulate host-level configurations that should be immutable from the sandboxed environment. It represents a classic case where API exposure is not sufficiently granular, granting broader permissions than intended for specific functions.
To mitigate this risk, organizations running vm2 must immediately upgrade to version 3.12.1 or later, which addresses the flaw by ensuring that crypto.setFips is properly sanitized and isolated from guest access. For environments where upgrading is not immediately feasible, a temporary workaround involves avoiding the exposure of the full crypto builtin module if FIPS mode stability is critical. Instead, developers should consider implementing custom wrappers for specific cryptographic functions needed by guest code, explicitly excluding any configuration or state-modifying methods like setFips and setEngine from being passed through to the host context. Additionally, monitoring logs for unexpected changes in cryptographic behavior can help detect exploitation attempts of this vulnerability before significant damage occurs.