Normalization logic within vm2 resolves this to the node:test module, providing the sandbox with a readonly proxy to the host's test-runner. Because this proxy forwards calls to the host implementation without sufficient API validation, an attacker can invoke node:test.run() and supply arbitrary execArgv flags. By passing flags such as --eval, the attacker can spawn a child process that executes arbitrary JavaScript in an unrestricted host Node.js environment, effectively escaping the vm2 sandbox boundary.

Attack Chain

1. Attacker identifies a target application utilizing vm2 with node:test explicitly enabled in the require.builtin configuration.
2. Attacker injects malicious JavaScript into the NodeVM sandbox environment.
3. Attacker invokes require('node:node:test') within the sandbox to bypass existing builtin restriction filters.
4. The vm2 sandbox normalizes the path to node:test and grants access to the host's test-runner module.
5. Attacker executes node:test.run() within the sandbox, supplying a crafted object containing malicious execArgv parameters.
6. The node:test runner spawns a new Node.js child process using the attacker-supplied execArgv arguments.
7. The child process executes the attacker's payload (e.g., --eval='require("fs").writeFileSync(...)') outside the sandbox, granting full access to the host system.

Impact

Successful exploitation allows an attacker to break out of the vm2 sandbox and execute code with the privileges of the host Node.js process. This leads to full system compromise, including unauthorized access to the host filesystem, environment variables, network resources, and other sensitive host-side data. The impact is critical as it invalidates the security boundary provided by the vm2 library.

Recommendation

1. Upgrade to a patched version of vm2 if available or transition to more secure sandboxing solutions, as the vm2 project has reached end-of-life.
2. Update the DANGEROUS_BUILTINS configuration in the vm2 library to include test to block access to the node:test module at the source.
3. Audit existing configurations to identify and remove node:test from any require.builtin allowlists.
4. If test capabilities are required, implement a sandbox-local wrapper that does not expose the run() method, execArgv, or any other host-process control parameters.