Kodove

**Name of the Vulnerable Software and Affected Versions** vm2 versions prior to 3.11.0 **Description** The `CallSite` wrapper class, designed as a safe wrapper for V8's native CallSite, fails to sanitize the output of the `getFileName()` function. While the class blocks `getThis()` and `getFunction()` to prevent host object leakage, `getFileName()` can return unsanitized absolute paths from the host. This allows sandboxed code to extract the host server's full directory structure, library paths, and framework versions. This information disclosure can occur via the default `error.stack` or by using a custom `prepareStackTrace` to call `getFileName()` on each CallSite. **Recommendations** Update to version 3.11.0.

**Name of the Vulnerable Software and Affected Versions** vm2 versions prior to 3.11.0 **Description** A performance optimization in the code transformer skips AST (Abstract Syntax Tree) analysis when the code does not contain the keywords `catch`, `import`, or `async`. This fast-path bypass allows sandboxed code to directly access the internal `VM2 INTERNAL STATE DO NOT USE OR PROGRAM WILL FAIL` variable, exposing internal security functions including `handleException()`, `wrapWith()`, and `import()`. This occurs because the AST visitor designed to block access to the internal state and the instrumentation for `with` statements are bypassed when the regex check is not triggered. **Recommendations** Update to version 3.11.0.

**Name of the Vulnerable Software and Affected Versions** vm2 versions prior to 3.11.0 **Description** A sandbox escape allows sandboxed code to crash the host Node.js process. This occurs when a `Promise` constructor triggers an unhandled rejection that propagates to the host. Specifically, when sandboxed code creates a `Promise` where the executor sets `Error.name` to a `Symbol()` and then accesses `.stack`, V8's internal `FormatStackTrace` attempts `Symbol.toString()`, throwing a host-realm TypeError. Because the `Promise` executor is not wrapped in a try-catch block in `lib/setup-sandbox.js`, and the `.then()` and `.catch()` overrides do not intercept rejections originating from the executor, the error becomes an unhandled rejection that terminates the host process. This results in a Denial of Service (DoS) where a single request can crash the entire server. Setting `allowAsync: false` does not prevent this and may exacerbate the issue by blocking `.catch()` method calls, ensuring the rejection remains unhandled. **Recommendations** Update to version 3.11.0 or later.

**Name of the Vulnerable Software and Affected Versions** vm2 versions prior to 3.11.0 **Description** Sandboxed code can call the `Buffer.alloc()` function with an arbitrary size to allocate memory directly on the host heap. Because `Buffer.alloc()` is a synchronous C++ native call, the `timeout` option cannot interrupt the execution. This allows a single request to exhaust host memory, leading to a process crash with a FATAL ERROR: Reached heap limit. The issue occurs because the `Buffer` object is exposed to the sandbox through the `HOST` object, and the bridge proxy in `lib/bridge.js` passes these calls to the host without size validation. **Recommendations** Update to version 3.11.0.

**Name of the Vulnerable Software and Affected Versions** LiquidJS versions prior to 10.25.1 **Description** LiquidJS’s `memoryLimit` security feature can be bypassed using reverse range expressions (e.g., `(100000000..1)`), allowing an attacker to allocate unlimited memory. When combined with a string flattening operation (e.g., the `replace` filter), this causes a V8 Fatal error that crashes the Node.js process, resulting in a denial of service from a single HTTP request. The attack payload is approximately 400 bytes. The vulnerability occurs because the `Limiter.use()` method does not validate that the `count` parameter is non-negative, allowing a negative value to be added to the internal counter. This allows subsequent memory allocations to bypass the configured `memoryLimit`. A cons-string flattening operation then triggers the V8 Fatal error. The issue can be exploited if an attacker can control Liquid template source code. **Recommendations** Versions prior to 10.25.1 should be updated to version 10.25.1 or later.

**Name of the Vulnerable Software and Affected Versions** LiquidJS versions prior to 10.25.1 **Description** LiquidJS is susceptible to a denial of service condition due to insufficient memory limit enforcement within the `replace first` filter. The filter utilizes JavaScript's `String.prototype.replace()`, which interprets `$&` as a back reference to the matched substring. This allows an attacker to achieve exponential memory amplification, potentially reaching a 625,000:1 ratio, while remaining within the defined `memoryLimit`. The `replace first` filter only accounts for the input string length when calculating memory usage, failing to consider the expanded output resulting from the `$&` expansion. This issue does not affect the `replace` or `replace last` filters, which handle `$&` as a literal string or use manual substring operations, respectively. A proof-of-concept (PoC) demonstrates that a small input string can be amplified to 312.5 MB, causing significant service disruption. Concurrent attacks with 20 requests can lead to legitimate user requests being delayed by up to 10.9 seconds, and the server becoming unresponsive for approximately 29 seconds. The vulnerability is triggered by crafting a malicious Liquid template containing repeated `$&` patterns within the `replace first` filter. The **API endpoint** used for exploitation is `/render`, which accepts user-provided Liquid templates via a POST request. The vulnerable parameter is `template`, which contains the malicious Liquid code. **Recommendations** Update LiquidJS to version 10.25.1 or later.