External risk intelligence

vm2 Remote Code Execution Vulnerability with Require External Enabled

CVE advisorySeverity: CRITICAL (CVSS 10.0)

CVE-2026-92946

The vulnerability exists in a JavaScript sandbox library (vm2) used by developers within applications. While it is a library rather than a standalone network service, it may be integrated into internet-facing web applications that process untrusted user-supplied code or templates, making it plausibly reachable via those application vectors in certain deployments.

Remote Code Execution

Halo Surface Signal: 3 out of 5 — possibly public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

This advisory highlights a critical vulnerability in a JavaScript sandbox library, vm2. The issue allows attackers to execute arbitrary commands on the host operating system when specific features are enabled, posing a significant risk if the library is used in applications processing untrusted code or templates. The main concern is confirming relevance and exposure within your environment.

Library allows code execution on host.
Potential for broad impact in web applications.
Confirm use and exposure to assess risk.

Attack Path

How an attacker could exploit the issue

An attacker could exploit this vulnerability by leveraging the `require.external` feature in a sandboxed environment without proper restrictions. If the `vm2` library is used in an application that allows executing untrusted code, and `require.external` is enabled without explicitly excluding `node_modules`, the attacker can trick the sandbox into loading `vm2` itself. This allows them to create an unrestricted `NodeVM` instance, which can then execute arbitrary operating system commands.

Remote unauthenticated access is required.
Sandboxed code triggers the vulnerability.
Arbitrary host OS command execution is possible.

Live Threat

Current exploitation, exposure, and threat context

This vulnerability could allow arbitrary commands to be executed on the host operating system when the `require.external` feature is enabled without proper configuration in the vm2 sandboxing library. This could occur when sandboxed code is able to bypass restrictions and leverage the `child_process` module.

Host OS command execution.
Sandboxed code bypasses restrictions.
Compromise of the underlying host system.

Operational Fix

Recommended remediation, mitigation, and detection steps

The vm2 library's remote code execution vulnerability requires careful consideration of application architecture. Teams responsible for applications that sandbox untrusted code or process user-supplied templates should prioritize identifying instances of vm2, assessing their exposure, and confirming ownership for remediation. The first practical step involves locating all deployments of the affected technology, determining their business criticality and reachability, and assigning accountability for managing the risk.

Application owners must be identified.
Verify sandbox code execution paths.
Plan remediation based on risk.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is the vm2 library and what is it used for?

vm2 is a JavaScript library designed to run untrusted code within a secure, isolated sandbox environment. Developers frequently use it in Node.js applications to safely execute user-supplied code or process dynamic templates without granting that code full access to the underlying system. It serves as a container to limit what scripts can see and do.

What does CWE-913 mean regarding CVE-2026-92946?

CWE-913 refers to improper control of dynamically-managed code resources. In this specific CVE, the sandbox fails to properly restrict the loading of external modules. Because the library allows the sandboxed environment to 'require' its own package, an attacker can bypass intended limitations to escape the sandbox and interact directly with the host system.

How is this sandbox escape triggered?

An attacker needs the application to process untrusted code where the `require.external` feature is active but lacks a restrictive `require.root` path. If the configuration does not explicitly block access to `node_modules`, the sandbox can be tricked into loading the library itself. This action creates a new, unrestricted environment that enables the execution of arbitrary operating system commands.

Is my application vulnerable according to Halo Surface Signal?

Halo Surface Signal indicates that while vm2 is a library rather than a standalone network service, your risk depends on how it is deployed. If your application is internet-facing and uses vm2 to process untrusted user input, it may be reachable via those web paths. The vulnerability is most relevant when the library is integrated into services that directly handle external requests.

What should I do first to address this risk?

Start by auditing your codebase to locate all instances where vm2 is implemented. Once identified, verify whether the `require.external` feature is enabled in your configurations. If it is, review your setup to ensure proper root directory restrictions are enforced. Prioritize these checks for applications that handle public-facing or untrusted user input.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.