Skip to content

Vm2 (virtual machine 2) is a library that provides a secure and sandboxed environment for executing JavaScript code, primarily used in server-side environments such
as Node.js.

It lets you create and run JavaScript code within a controlled environment, providing an extra layer of security by isolating code execution from your main application. Thus, potentially unsafe or untrusted code can be executed without impacting the stability or security of the hosting application. Eval (a JS function) is used instead of the vm2 position when the latter isn’t present, which causes some serious security issues. eval and the vm2 library are both related to dynamically executing JavaScript code. But if user input is directly passed to eval, it can allow arbitrary code execution, while vm2 provides a sandbox environment and restricts access to specific global objects or functions. Vm2 can also be used to do malware analysis, testing, and code debugging using an online code editor (if a user writes some malicious code), et al. Npm is a JS package manager; some npm packages use vm2 as dependencies to name popular packages, e.g., Cloudinary and Puppeteer.

Into the Depths – Exploring Vulnerabilities Impacting Vm2's Sandbox Integrity

A vulnerability has recently been discovered in the widely used vm2 library; it raises concerns about the integrity of its sandboxing capabilities. The vulnerability allows attackers to bypass the built-in sandbox and gain unauthorized access, thus enabling them to execute arbitrary code within the environment. Such an exploit undermines the core purpose of vm2 as a secure JS execution environment. With the ability to execute arbitrary code, adversaries can potentially perform malicious activities, compromise sensitive data, and/or exploit system vulnerabilities. This revelation calls for immediate attention by developers and users relying on vm2; you should reassess your security measures and implement appropriate safeguards to mitigate the risk of exploitation. Let’s explore the CVEs that unravel vm2's sandbox security capabilities and their impact on JavaScript applications.



This vulnerability is related to using err.name.toString in the ErrorPrototypeToString function, which is called from the host context. The issue arises because the error argument of the prepareStackTrace function is not handled properly by handlers defined in vm2/lib/bridge.js. This is due to prepareStackTrace being called directly by the V8 engine without going through proxy handlers. The behavior of a proxy object's [[Call]] internal method is relevant. It points to the creation of argArray in the host context and the host object being passed to apply(target, thiz, args). This suggests that accessing the Function constructor of the host context is possible, which could be a security concern in the vulnerable code. This vm2 vulnerability is related to the mishandling of the error argument in the prepareStackTrace function, potentially allowing unauthorized access to the Function constructor in the host context. The sandbox escape vulnerability affects vm2 versions up to 3.9.17. Exploiting it could enable a malicious actor to bypass the protective sandbox measures. Once they’re circumvented, an attacker can execute arbitrary code on the respective host system remotely.

image-png-4 1

Figure 2 - Output of malicious code (cal/etc/passwd)

blog_1 1

How to Identify Vulnerable Systems

That said, if a vulnerable vm2 version is installed in your system, Uptycs XDR has you covered. Its scanning detects such vulnerabilities, so you don’t have to worry much. Its vulnerabilities table stores scan results that can be queried as follows: