Forrof

**Name of the Vulnerable Software and Affected Versions** vm2 versions 3.11.3 through 3.11.6 **Description** When the `builtin: ['*']` configuration or explicit permission is granted, the host `node:sqlite` module is exposed to code running in NodeVM. Although the module is wrapped with `vm.readonly()` to prevent property assignment, host-authority callables remain reachable. A flaw in the resolver allows a request for `node:node:sqlite` to resolve to the `node:sqlite` entry because the runtime only strips one `node:` prefix. This enables sandboxed code to create an in-memory `DatabaseSync` with extension loading enabled and execute `DatabaseSync.loadExtension()` on a native library. Consequently, the library is loaded into the Node.js host process, allowing arbitrary native code execution with the privileges of the host process. **Recommendations** Update to version 3.11.7.

**Name of the Vulnerable Software and Affected Versions** vm2 versions 3.11.3 through 3.11.6 **Description** When the crypto builtin is allowed, the host Node.js crypto module is exposed to a NodeVM sandbox. Although the module is presented via a recursive read-only proxy, its callable exports still execute with host-process authority. This allows sandboxed JavaScript to call the `setEngine()` function with a filesystem path to an attacker-supplied native library. OpenSSL then requests the operating-system dynamic loader to load the file, causing the library's constructor to execute native code in the host process before engine-symbol validation rejects it. This leads to a sandbox escape and arbitrary native code execution, requiring only the crypto builtin without needing access to `fs`, `process`, `module`, `child process`, `worker threads`, `vm`, or `inspector`. **Recommendations** Update to version 3.11.7. As a temporary workaround, restrict the use of the crypto builtin in the NodeVM sandbox.

**Name of the Vulnerable Software and Affected Versions** vm2 versions 3.11.3 through 3.11.6 **Description** When a NodeVM is configured to allow `require('https')`, the host process's `https.globalAgent` is exposed to sandboxed code. Although the builtin loader uses a read-only proxy for host modules, method calls like `Agent.prototype.on()` are forwarded to the host object. This allows sandboxed code to register a listener for the `free` event of the agent. When a host HTTPS request releases a pooled connection, the listener gains access to the host request options and the host `TLSSocket`. Consequently, sandboxed code can read the `Authorization` header and private destination host/port, intercept subsequent host response bodies in plaintext, and perform authenticated requests using stolen credentials. **Recommendations** Update vm2 to version 3.11.7.

**Name of the Vulnerable Software and Affected Versions** vm2 versions 3.11.3 through 3.11.6 **Description** The host tls module is exposed to NodeVM sandbox code, which allows attackers to call the `setDefaultCACertificates()` function and replace process-wide certificate authorities. By utilizing allowed tls and url builtins, attackers can use `URLSearchParams` to create host-realm arrays and manipulate the TLS trust store. This enables subsequent host HTTPS clients to accept certificates controlled by the attacker, leading to a full sandbox escape. **Recommendations** Update vm2 to version 3.11.7 or later.