Kodove

**Nome do Software Vulnerável e Versões Afetadas** vm2 versões anteriores a 3.11.0 **Descrição** A classe wrapper `CallSite`, projetada como um wrapper seguro para o CallSite nativo do V8, não sanitiza a saída da função `getFileName()`. Embora a classe bloqueie `getThis()` e `getFunction()` para evitar o vazamento de objetos do host, a função `getFileName()` pode retornar caminhos absolutos não sanitizados do host. Isso permite que o código em sandbox extraia a estrutura completa de diretórios, caminhos de biblioteca e versões de framework do servidor host. Essa divulgação de informações pode ocorrer por meio do `error.stack` padrão ou usando um `prepareStackTrace` personalizado para chamar `getFileName()` em cada CallSite. **Recomendações** Atualize para a versão 3.11.0.

**Nome do Software Vulnerável e Versões Afetadas** vm2 versões anteriores a 3.11.0 **Descrição** Existe um problema de escape de sandbox onde o código executado na sandbox pode travar o processo host do Node.js. Isso ocorre quando um construtor de `Promise` dispara uma rejeição não tratada (unhandled rejection) que se propaga para o host. Especificamente, se um executor de `Promise` define `Error.name` como um `Symbol()` e então acessa `.stack`, a função interna `FormatStackTrace` do V8 tenta realizar uma operação `Symbol.toString()`, o que lança um `TypeError` no reino do host. Como o erro se origina dentro do executor e não possui um manipulador `.catch()`, ele resulta em uma rejeição não tratada que encerra o processo host. Detalhes técnicos incluem: - O wrapper `localPromise` em `lib/setup-sandbox.js:38` não envolve o executor em um bloco try-catch. - O `resetPromiseSpecies` e as sobrescritas de `.then()` e `.catch()` em `lib/setup-sandbox.js:165-230` não interceptam rejeições originadas do próprio executor. - A configuração `allowAsync: false` não mitiga o problema porque o construtor de `Promise` continua disponível, e o bloqueio do `.catch()` garante que a rejeição permaneça não tratada. Isso pode levar a um loop contínuo de negação de serviço (DoS), onde o processo host trava ao receber uma única requisição, potencialmente ignorando políticas de reinicialização automática. **Recomendações** Atualize o vm2 para a versão 3.11.0.

**Nome do Software Vulnerável e Versões Afetadas** vm2 versões anteriores a 3.11.0 **Descrição** Uma otimização de desempenho no transformador de código ignora a análise AST (Abstract Syntax Tree) quando o código não contém as palavras-chave `catch`, `import` ou `async`. Esse bypass de caminho rápido permite que o código em sandbox acesse diretamente a variável interna `VM2 INTERNAL STATE DO NOT USE OR PROGRAM WILL FAIL`, expondo funções de segurança internas, incluindo `handleException()`, `wrapWith()` e `import()`. Isso ocorre porque o visitante AST projetado para bloquear o acesso ao estado interno e a instrumentação para instruções `with` são ignorados quando a verificação de regex não é acionada. **Recomendações** Atualizar para a versão 3.11.0.

**Nome do Software Vulnerável e Versões Afetadas** vm2 versões anteriores a 3.11.0 **Description** Código em sandbox pode chamar a função `Buffer.alloc()` com um tamanho arbitrário para alocar memória diretamente no heap do host. Como o `Buffer.alloc()` é uma chamada nativa síncrona de C++, a opção `timeout` fornecida pelo vm2 não consegue interromper a execução. Isso permite que uma única requisição esgote a memória do host e cause a falha do processo com um FATAL ERROR: Reached heap limit, resultando em negação de serviço. Este problema é particularmente grave em ambientes com memória limitada, como Docker, pods Kubernetes ou AWS Lambda, onde pode causar um travamento imediato por falta de memória (OOM). **Recommendations** Atualize o vm2 para a versão 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.