Inspect method manipulation in vm2

Vulnerability

Overview

The vm2 sandbox library for Node.js, in versions 3.9.17 and lower, contains a vulnerability that allows untrusted code running inside the sandbox to obtain a read-write reference to Node's built-in inspect method. This is made possible through a chain of proxy traps and interactions with Node's internal error handling, as demonstrated in a proof-of-concept [3]. The root cause lies in the complex proxy-based isolation mechanism, which can be circumvented by leveraging prototype manipulation and the Buffer.prototype.copy binding [3].

Exploitation

Requirements

An attacker must be able to execute arbitrary JavaScript code within a vm2 sandbox instance. No additional authentication or network position is required beyond the ability to run code in the sandbox. Exploitation does not require any special permissions or prior knowledge of the host environment, as the attack is carried out entirely through JavaScript features available within the sandbox [1][3]. The sandbox's own proxy interception is subverted by triggering internal Node.js operations that invoke util.inspect with a crafted proxy [3].

Impact

Successful exploitation grants the attacker the ability to modify the options object for console.log calls [2][4]. While this does not directly enable arbitrary code execution outside the sandbox, it can be used to interfere with logging behavior, potentially to hide malicious activity or to cause denial of service (e.g., by making console.log crash or produce infinite output). The vendor notes that this is a sandbox bypass that weakens the isolation guarantees provided by vm2 [1][4].

Mitigation and

Status

A fix was released in vm2 version 3.9.18, and users are strongly advised to upgrade immediately [2][4]. For those who cannot upgrade, a workaround exists: after creating a VM, make the inspect method read-only by calling vm.readonly(inspect) [2][4]. Given the active development of bypasses for vm2, the project's maintainers recommend evaluating more robust isolation alternatives such as isolated-vm, worker threads, or container-level sandboxing [1].