# Critical Remote Code Execution Flaw in Widely Used Node.js vm2 Sandbox Library GitLab's Threat Research Group discovers a severe sandbox escape vulnerability in popular vm2 package. - **Source:** [GitLab](https://brifing.si/source/76101668-80db-4240-8676-e968d2b72546) - **Published:** 2026-09-02 - **Topic:** [Software & Engineering](https://brifing.si/c/engineering) - **Original article:** - **On Brifing:** https://brifing.si/s/1a8f9b26-01a1-4268-808f-5d5764c406f3 ## Critical Vulnerability Discovery GitLab's Threat Research Team identified a critical security flaw in vm2, a widely used Node.js sandboxing library. Rated CVSS 3.1: 10.0, this vulnerability enables remote code execution. Ironically, the issue stems from default configurations recommended in the library's own README file. All users running vm2 versions 3.11.6 or earlier must take immediate action to mitigate this risk. ## Technical Breakdown The vulnerability exists in vm2's NodeVM module configuration, specifically when require.external is enabled with broad root path settings. This combination allows malicious code to escape the sandbox by accessing the library's real copy through ./node_modules. What appears as a security measure (root path restriction) actually becomes the attack vector, completely bypassing sandbox protections. ## Attack Methodology Attackers can exploit this flaw by requiring vm2's own package from within the sandbox (require('./node_modules/vm2')). This grants access to the real library instance, enabling creation of a new NodeVM with dangerous modules like child_process enabled. While direct access to system modules remains blocked, this indirect method successfully bypasses all sandbox restrictions. ## Patch and Mitigations The vm2 maintainers promptly released version 3.11.7 to address this specific attack vector. However, security experts warn this doesn't fully resolve the underlying configuration risks. Developers must additionally restrict require.root paths and explicitly set context: 'sandbox'. For high-risk scenarios, experts recommend abandoning vm2 in favor of stronger isolation methods like containers. ## Historical Context This isn't vm2's first sandbox escape vulnerability. Previous issues like GHSA-8hg8-63c5-gwmx (nesting bypass) and GHSA-cp6g-6699-wx9c (symlink bypass) were patched in 2022. The current vulnerability exploits an entirely different code path, suggesting fundamental design flaws in the library's architecture that make it prone to such bypass techniques. ## Affected Systems Applications most at risk include plugin systems, code playgrounds, CI test runners, and AI-generated code execution environments - all common use cases for vm2. Major tech companies, cloud providers, and open source projects are potentially affected. GitLab confirmed they don't use vm2 in their own systems, demonstrating proactive security practices. ## Immediate Actions All developers must upgrade to vm2 3.11.7 immediately. However, this alone isn't sufficient - require.root must be narrowed to exclude ./node_modules, and context should be explicitly set to 'sandbox'. Ideally, require.external should be disabled entirely unless absolutely necessary. Without these additional measures, systems remain vulnerable to similar attack vectors. ## Long-term Recommendations Security professionals advise against relying on vm2 for isolating truly untrusted code, especially in AI-related applications. More robust solutions like Docker containers, microservice architectures, or full virtual machines provide stronger security guarantees. The JavaScript ecosystem particularly needs better sandboxing solutions that don't share Node's process space. ## Industry Impact This incident highlights fundamental challenges in software sandboxing technologies. Given vm2's popularity in the Node.js ecosystem, the vulnerability's impact is widespread. Security researchers warn that similar sandbox libraries likely contain comparable flaws. The event underscores the importance of open source security and dependency management in modern software development. ## Discovery Process GitLab's team discovered this vulnerability using their AI-powered automated security scanning tools. Following responsible disclosure practices, they privately notified vm2 maintainers, enabling a rapid patch development cycle. GitLab's transparency in confirming they don't use vm2 themselves sets a positive example for the industry in vulnerability handling and communication. ## Key Takeaways This incident serves as a stark reminder that even documentation-recommended configurations can introduce severe security risks. Developers must carefully evaluate sandbox solutions and never rely on default settings for security-critical features. Continuous monitoring of open source dependencies and their security updates remains essential in maintaining application security in today's complex software landscape. ## Sources covering this story - https://about.gitlab.com/blog/critical-remote-code-execution-in-vm2/ — --- _Summary written by Brifing from the original reporting. Copyright in the original article belongs to its publisher; read the full piece at the link above._