External risk intelligence

vm2 Prototype Pollution Allows Host Modification

CVE advisorySeverity: CRITICAL (CVSS 9.3)

CVE-2026-92953

vm2 is a server-side JavaScript sandbox library designed to be imported as a dependency in software development. It is not an internet-facing service, appliance, or gateway, and its exposure depends entirely on how a developer implements it within their own application code, making direct public internet exposure very unlikely by design.

Halo Surface Signal: 1 out of 5 — much less likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

A vulnerability has been identified in the vm2 JavaScript sandbox library that could allow unauthorized modification of critical system components. This issue arises from improper handling of internal data structures within the sandbox, potentially enabling malicious actors to alter how the host system processes certain data types. The primary concern is confirming whether your environment utilizes this specific library and is therefore exposed.

A library flaw allows tampering with data handling.
Leadership should remember potential system instability.
Confirm if this library is used in your systems.

Attack Path

How an attacker could exploit the issue

An attacker could exploit this vulnerability by manipulating the JavaScript environment within the vm2 sandbox. Specifically, they can alter the fundamental behavior of core JavaScript objects like TypedArrays and ArrayBuffers. This manipulation allows them to influence how data is handled after a sandbox operation completes, potentially leading to the execution of unintended code or unauthorized modifications.

No special access needed.
Modifies JavaScript prototypes.
Potential for code execution and data tampering.

Live Threat

Current exploitation, exposure, and threat context

The vm2 sandbox can be tricked into modifying host-created typed arrays. When an attacker can influence the properties of these arrays after they've been created by the host, it could lead to unexpected and potentially harmful service behavior when the sandbox execution finishes.

Host typed arrays could be modified.
Attackers could use prototype-walking.
Service behavior could become unpredictable.

Operational Fix

Recommended remediation, mitigation, and detection steps

The vm2 library's handling of `TypedArray` and `ArrayBuffer` prototypes presents a critical risk, allowing attackers to manipulate host environment properties. Ownership likely falls to the application development or platform engineering teams responsible for the code that integrates vm2. The immediate priority is to locate all instances of the affected library, assess their reachability and business criticality, and identify the specific owner for each instance to plan a targeted remediation.

Application owners, platform teams.
Verify vm2 instances and reachability.
Plan remediation based on identified 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 used for?

vm2 is a Node.js library designed to run untrusted JavaScript code securely by isolating it in a sandbox. Developers use it to execute user-provided scripts or plugins within an application without allowing that code to access the underlying host system or sensitive data. It acts as a safety layer between your application logic and potentially malicious external code.

What is the vulnerability in CVE-2026-92953?

This vulnerability is a form of prototype pollution, classified as CWE-913. It occurs because the library fails to properly isolate the sandbox from the host's fundamental memory structures, specifically TypedArray and ArrayBuffer prototypes. By manipulating these shared structures, an attacker can escape the sandbox's constraints and influence the behavior of the host application even after the sandboxed code finishes running.

How does an attacker trigger this bug?

An attacker must be able to execute arbitrary JavaScript within the vm2 sandbox environment. The bug is triggered when the attacker uses prototype-walking techniques to traverse and modify global objects that the sandbox should not have access to. Simply having the library installed is not enough; the vulnerability requires an active execution path where untrusted code is processed by the library.

Is my system at risk if I use vm2?

According to Halo Surface Signal, vm2 is a code dependency rather than a standalone service, making direct public internet exposure very unlikely. Your risk depends on whether your application accepts and processes untrusted input through this library. If your application code is purely internal and does not handle user-provided scripts, the practical risk is significantly lower than for public-facing platforms.

How should I respond to this threat?

First, identify all software projects in your environment that list vm2 as a dependency in their manifest files. Once identified, work with your development teams to determine if the library processes untrusted input, which dictates the severity. The primary remediation is to update to a version of vm2 that includes the fix for prototype pollution, ensuring your sandbox integrity is restored.

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.