CVE Vulnerability Catalog

SGLang through 0.5.19 in prefill/decode disaggregation mode contains an unauthenticated PUT /route endpoint on the prefill bootstrap service that allows attackers to poison the KV transfer routing table. Attackers can supply arbitrary rank_ip and rank_port values to redirect decode workers to attacker-controlled endpoints, causing denial of service or disclosure of KV transfer metadata including session identifiers and tensor-parallel topology parameters.

InternLM LMDeploy through 0.17.0 contains a reachable assertion vulnerability in the DistServe decode migration loop that allows unauthenticated attackers to terminate the inference engine. Attackers can submit a migration_request with an empty remote_block_ids list to trigger an AssertionError that crashes the engine loop and causes subsequent inference requests to fail.

HUBzero CMS through 2.2.32 contains a path traversal vulnerability in project file upload handlers that allows authenticated project members to write arbitrary files outside the project repository. Attackers can supply traversal sequences in upload parameters to write files to attacker-chosen paths with web server privileges, potentially enabling code execution.

vm2 versions before 3.11.2 fail to properly restrict access to the VM2_INTERNAL_STATE_DO_NOT_USE_OR_PROGRAM_WILL_FAIL global variable. Attackers can access this internal state object through globalThis to retrieve sensitive sandbox internals.

vm2, a sandbox for running untrusted JavaScript, in versions up to and including 3.11.3 uses prototype-walking index assignment in defaultSandboxPrepareStackTrace, allowing sandbox code to intercept error stack lines. The impact is low (information side channel) and the issue is fixed in version 3.11.4.

vm2 before 3.11.6 fails to enforce bufferAllocLimit on ArrayBuffer, SharedArrayBuffer, and TypedArray constructors, allowing attackers to allocate arbitrary host memory. Attackers can bypass the buffer allocation cap by using these V8 intrinsics to exhaust host process memory and trigger out-of-memory conditions.

In vm2 before 3.11.6, the builtin: ['*'] configuration does not restrict access to os and dns builtins, allowing sandbox code to read host process identity and network topology. Attackers can use dns.setServers() to hijack the host process's DNS resolver globally.

vm2 before 3.11.8 does not fully enforce the allowAsync: false option in VM and NodeVM. While localPromise.prototype.then is replaced with a handler that throws 'Async not available', the sandbox's Promise static methods (Promise.resolve, Promise.all, Promise.race, Promise.any, and Promise.allSettled) still assimilate attacker-supplied thenables, allowing sandboxed script to schedule work that runs after VM.run() or NodeVM.run() has returned and outside the configured timeout.

vm2 through 3.11.6 contains a builtin-module denylist bypass in NodeVM. When the embedder uses the builtin wildcard together with negative entries (e.g. require: { builtin: ['*', '-fs', '-child_process'] }), negative entries are matched by exact module name, so -fs removes only the builtin named fs and does not remove builtin subpaths such as fs/promises. Sandboxed code can therefore call require('fs/promises') or require('node:fs/promises') and reach the promise-based filesystem API despite fs being denied.

vm2 through 3.11.6 does not normalize 'node:'-prefixed builtin specifiers when matching negative (deny) entries in a NodeVM wildcard require policy. A policy such as ['*', '-node:child_process'] fails to deny the canonical child_process module because matching uses exact string comparison against canonical builtin names. Sandboxed code can therefore obtain the host child_process builtin and gain access to process-spawning APIs such as execSync and spawn, equivalent to host command execution.

In vm2 versions 3.10.1 through 3.11.6, there is a sandbox escape via WebAssembly.compileStreaming and instantiateStreaming, allowing attackers to access the host process object on Node.js 26, leading to full host control.

In vm2 before 3.11.8, there is a sandbox escape vulnerability via console._stdout and console._stderr. Attackers can overwrite EventEmitter.prototype.emit and execute code on the host process, bypassing code generation restrictions.

vm2 versions >= 3.10.0 and <= 3.11.7 do not mark Promises returned from the host realm into the sandbox as handled at the bridge boundary. Only Promises created inside the sandbox are wrapped with a rejection-swallowing handler, and the bridge only installs host-side rejection sanitizers when sandbox code calls .then/.catch/.finally. As a result, sandboxed code can invoke a host function that returns a rejected Promise and ignore the return value, leaving the host Promise unhandled so that Node.js's default unhandled-rejection behavior terminates the host process.

In vm2 versions from 3.11.0 before 3.11.8, host TypedArray and ArrayBuffer prototypes are not protected from sandbox mutation. Attackers can modify prototypes, affecting host-created typed arrays and potentially leading to unauthorized actions.

vm2 versions 3.11.4 through 3.11.6 incompletely filter Node.js registered internal symbols across the sandbox boundary. The extraction filters in lib/setup-sandbox.js and the cross-realm symbol checks and write traps in lib/bridge.js use a fixed list of known dangerous registered symbols that omits nodejs.stream.disturbed and nodejs.stream.errored, which are exposed on host WebStream prototypes on newer Node.js releases. When the embedder exposes a host WebStream object and the host stream/web module to the sandbox, sandbox code can obtain the real host symbols and use them as write keys on host stream objects, corrupting host-visible stream state. This can bypass host logic that relies on Node's public stream-state helpers. It is not a host code-execution primitive in the reported proof of vulnerability. This is an incomplete fix for the earlier nodejs.* symbol filtering issue. Fixed in vm2 3.11.7.

vm2 before 3.11.7 contains an incorrect authorization vulnerability in the external package allowlist check that uses non-exact substring matching instead of full package-name boundary validation. Attackers can bypass the allowlist by requiring a colliding package name that contains an allowlisted package substring, causing vm2 to load and execute unauthorized host packages in the host context.

A vulnerability in the vm2 CLI tool (before 3.11.7) allows sandbox escape and arbitrary code execution in the host Node.js process. Attackers can supply a malicious script that uses require(__filename) to re-execute itself in the host realm, bypassing sandbox isolation and accessing host modules like fs and child_process.

vm2 versions from 3.9.6 before 3.11.7 fail to properly restrict access to accessor properties on frozen objects, allowing sandboxed scripts to bypass vm.freeze() and vm.readonly() protections. Attackers can use Object.getOwnPropertyDescriptor() or __lookupSetter__() to extract and invoke host object setters directly, mutating properties the embedder explicitly marked read-only.

vm2 versions >= 3.9.6 and <= 3.11.6 are affected by a NodeVM builtin allowlist bypass that permits a sandbox escape on Node.js 24 and newer when the embedder explicitly allows the node:test builtin. On Node.js 24+, module.builtinModules exposes the scheme-only key node:test, which is not covered by vm2's family-based DANGEROUS_BUILTINS protection, and because requireImpl() strips only a single 'node:' prefix, sandbox code calling require('node:node:test') receives a proxy to the host module, with node:test.run() forwarding attacker-controlled execArgv (e.g. --eval) to execute arbitrary JavaScript in an unrestricted host process.

vm2 before 3.11.7 exposes Node's shared Buffer pool to sandboxed code, allowing disclosure of host memory used by Buffer.from, Buffer.concat, and related allocations. Sandboxed code can read and write to host-realm buffers by acquiring ArrayBuffers from small allocations, leading to sensitive data exposure and potential denial-of-service.