CVE Vulnerability Catalog

vm2 before 3.11.7 contains a remote code execution vulnerability when require.external is enabled without an explicit require.root that excludes node_modules. Sandboxed code can require vm2's own package, instantiate an unrestricted NodeVM instance, and execute arbitrary host OS commands via child_process.

vm2 before 3.11.7 contains a module allowlist bypass vulnerability in isPathAllowedForModule that uses raw string prefix matching instead of boundary-anchored comparison. Attackers can reach non-allowlisted packages sharing a prefix with allowlisted modules by performing relative requires from allowlisted packages when transitive loading is disabled.

vm2 versions 3.10.2 through 3.11.6 contain a sandbox escape vulnerability on Node.js 26 where Promise.prototype.finally() bypasses vm2's wrapper protections due to a stale PromiseThenLookupChain protector in V8 14.6. Attackers can exploit this by creating an async function that returns a Promise with an attacker-controlled constructor Symbol.species, allowing them to reach the host Function constructor and process object for arbitrary code execution.

In vm2 versions ≤ 3.11.6, the VM({ timeout }) option is not enforced for code executed outside the synchronous VM#run() call. Sandboxed code can register a FinalizationRegistry callback and, after dropping an object reference, block the host event loop indefinitely, causing denial of service.

vm2 versions from 3.11.3 before 3.11.7 expose the host tls module to NodeVM sandbox code, allowing attackers to call tls.setDefaultCACertificates() and replace process-wide certificate authorities. Attackers with access to allowed tls and url builtins can use URLSearchParams to create host-realm arrays and manipulate the TLS trust store, enabling subsequent host HTTPS clients to accept attacker-controlled certificates.

vm2 versions 3.11.3 through 3.11.6 expose the host process's real https.globalAgent to sandboxed code when a NodeVM is explicitly configured to allow require('https'). Although host modules are wrapped in a read-only proxy, method calls such as Agent.prototype.on() are forwarded to the underlying host object, so sandbox code can register a listener for the agent's 'free' event. When an unrelated host HTTPS request releases a pooled connection, the listener receives the live host request options and the host TLSSocket, allowing sandboxed code to read the host's Authorization header and private destination host/port, read subsequent host response bodies in plaintext, and issue attacker-chosen authenticated requests using the stolen credentials.

vm2 3.11.3 through 3.11.6 exposes the host Node.js crypto module to a NodeVM sandbox when the crypto builtin is allowed. The module is presented via a recursive read-only proxy, but its callable exports still execute with host-process authority, so sandboxed JavaScript can call crypto.setEngine() with a filesystem path to an attacker-supplied native library; OpenSSL asks the operating-system dynamic loader to load the file, and the library's constructor executes native code in the host process before engine-symbol validation rejects it. Exploitation requires only the crypto builtin and results in a sandbox escape and arbitrary native code execution.

vm2 versions 3.11.3 through 3.11.6 expose Node.js's host node:sqlite module to code running in NodeVM when that builtin is permitted, either explicitly or through builtin: ['*']. The module is wrapped with vm.readonly(), which prevents property assignment but leaves host-authority callables reachable; in addition, the resolver treats any request starting with 'node:' as a core-module request and the runtime strips only one 'node:' prefix, so a sandbox request for 'node:node:sqlite' resolves to the configured node:sqlite entry. Sandboxed code can therefore create an in-memory DatabaseSync with extension loading enabled and call DatabaseSync.loadExtension() on a native library bundled in the untrusted plugin package, giving the sandboxed plugin arbitrary native code execution outside the sandbox with the host process's privileges.

vm2 3.11.6 is vulnerable to a sandbox escape leading to remote code execution in the host Node.js process. The fix for GHSA-m283-3h24-438v is incomplete: the bridge gate at lib/bridge.js:1624 identity-checks only the direct call target when deciding whether to rebuild/sanitise a rejected host Promise value. Registering the rejection handler through Function.prototype.call or .apply indirection (e.g., p.then.call(p, undefined, cb)) makes the intercepted target host Function.prototype.call, so the sanitiser never runs and the raw host error reaches sandbox code with its own properties intact. If an embedder exposes a host-realm Promise to the sandbox and that Promise rejects with an Error carrying a non-primitive own property referencing a host object (for example err.detail = process), untrusted code in the sandbox obtains a fully functional proxy to that host object and can execute arbitrary commands with the privileges of the host process.

vm2 versions 3.11.0 through 3.11.6 leak absolute host filesystem paths to sandboxed code through error stack formatting. Attacker-supplied code can force the host-realm source transformer to throw a SyntaxError and then read the error's .stack property, bypassing the sandbox-side host-path redaction. Default new VM() and new NodeVM() configurations are affected without any special options.

vm2, a sandbox for running untrusted Node.js code, in versions 3.11.4–3.11.6 incorrectly treats an array passed as the 'require' option (e.g. require: []) as a valid configuration, bypassing the guard meant to reject nesting without an explicit require configuration. An attacker can then require the host vm2 module, create an inner NodeVM with an attacker-chosen builtin allowlist (such as child_process), and execute arbitrary commands with the privileges of the host Node.js process, escaping the sandbox. This is fixed in vm2 3.11.7.

vm2 before 3.11.8 contains an incomplete fix for Error.cause sanitization that allows sandbox escape when revisited host-wrapped AggregateError objects are caught within a single exception handler traversal. Attackers can exploit a cycle detection bypass in handleException to access unsanitized host proxies embedded in the errors array, enabling full remote code execution and process information disclosure from the sandbox.

vm2 is a sandbox for running untrusted Node.js code. In versions <= 3.11.7, NodeVM exposes the host util module to the sandbox as an unfiltered shallow copy, and the deprecated sys builtin is exposed through the generic builtin loader. On Node.js >= 22.9 this hands sandboxed code util.getCallSites(), which returns the host process's full call stack, including absolute file paths, function names, and line numbers. Fixed in vm2 3.11.8.

A security flaw has been discovered in vgmstream up to r2117. This issue affects the function parse_mus of the file src/meta/mus_acm.c. The manipulation results in resource consumption. The attack may be launched remotely. The patch is identified as ae37662ad626254ddd96ad69ac263792d7a92024.

An unauthenticated Cross-Site Scripting (XSS) vulnerability in Visitor Traffic Real Time Statistics Pro versions ≤ 11.21 allows attackers to inject malicious scripts without authentication.

An unauthenticated Cross-Site Scripting (XSS) vulnerability in WP Inventory Manager versions ≤ 2.5.4 allows attackers to execute scripts in the victim's browser without authentication.

google-protobuf contains unbounded recursion when parsing unknown protobuf group fields. An attacker can send a small crafted payload of deeply nested START_GROUP wire bytes to a Node.js service calling deserializeBinary(), causing a RangeError: Maximum call stack size exceeded and crashing the process.

Insufficient Session Expiration vulnerability in team-alembic AshAuthentication and AshAuthentication Phoenix allows a revoked session to remain fully authenticated. A resource configured with session_identifier :jti and require_token_presence_for_authentication? disabled stores its session value as <jti>:<subject>, but the session readers discard the jti and pass the bare subject, never consulting the revocation record. As a result, a session captured before sign-out keeps working.

Improper Output Neutralization for Logs vulnerability in team-alembic AshAuthentication allows an unauthenticated attacker to forge application log entries by submitting a password reset identity containing newlines or control characters. AshAuthentication.Strategy.Password.RequestPasswordReset.run/3 interpolates the identity argument into its Logger.warning/1 heredocs without escaping, truncating or type-restricting it. This issue affects ash_authentication: from 4.2.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14.

Authentication Bypass by Primary Weakness vulnerability in team-alembic AshAuthentication allows an unconfirmed user to obtain a session, defeating a mandatory email confirmation requirement. check_user/2 decides whether the require_confirmed_with attribute is set using a bare is_nil(Map.get(user, value)); when the attribute is not loaded it returns %Ash.NotLoaded{} and when a field policy denies it returns %Ash.ForbiddenField{}, neither of which is nil, so the rejection branch is skipped. Additionally, the check is not enforced when the action is invoked directly by an API layer such as AshGraphql or AshJsonApi.