Ulises Gascón

O middleware de logging não neutraliza caracteres de controle quando o token `:remote-user` extrai o nome de usuário de autenticação Basic do cabeçalho de requisição Authorization. Um invasor não autenticado pode enviar um cabeçalho Authorization Basic manipulado contendo bytes de Carriage Return (CR) ou Line Feed (LF) para injetar linhas de log forjadas. Isso quebra a estrutura de uma requisição por linha dos logs de acesso, permitindo a falsificação de logs para consumidores de log downstream. O problema afeta os formatos integrados combined, common, default e short, bem como qualquer formato personalizado que referencie `:remote-user`.

Ocorre uma negação de serviço devido a uma exceção não capturada durante a análise de requisições `multipart/form-data`. Quando uma requisição contém um cabeçalho `Content-Disposition` com um parâmetro `filename*` que apresenta codificação de percentagem malformada, o analisador chama a função `decodeURI()` sem um bloco try/catch. Isso resulta em um `URIError` que interrompe o processo, afetando qualquer serviço que aceite uploads multipart através desta biblioteca.

Ocorre uma negação de serviço quando uma requisição multipart/form-data é enviada com um nome de campo que colide com uma propriedade herdada do Object.prototype, como ` proto `, `constructor` ou `toString`. Isso faz com que o analisador invoque a função `.push()` no valor do protótipo herdado em vez de um array, resultando em um TypeError que gera uma exceção não capturada e interrompe o processo. Este problema afeta qualquer serviço que aceite uploads multipart via multiparty.

Um problema de negação de serviço ocorre devido ao backtracking de expressão regular no analisador de parâmetros de nome de arquivo do Content-Disposition. Um upload multipart manipulado contendo um valor de cabeçalho longo pode fazer com que a correspondência de regex leve vários segundos, bloqueando o loop de eventos. Isso afeta qualquer serviço que aceite uploads multipart usando esta biblioteca.

Ocorre a exposição de código-fonte entre origens ao servir através de uma origem não potencialmente confiável, como HTTP simples. O problema surge porque a correção anterior dependia dos cabeçalhos de requisição `Sec-Fetch-Mode` e `Sec-Fetch-Site`, que os navegadores omitem para origens não confiáveis. Isso permite que um site malicioso carregue o código agrupado como um script e o leia entre origens. Um invasor que controle um site visitado por um desenvolvedor pode recuperar o código-fonte da aplicação se o servidor for executado via HTTP em um host e porta previsíveis. Navegadores baseados em Chromium a partir do Chrome 142 não são afetados devido a restrições de acesso à rede local.

A função `normalize()` decodificava delimitadores de autoridade percent-encoded dentro do componente de host e os reemitia como delimitadores brutos durante a serialização. Isso permite que um host que combine um domínio permitido, um sinal de arroba codificado e um domínio diferente seja reemitido com o sinal de arroba como um separador de userinfo bruto, alterando a autoridade da URI para o segundo domínio. Aplicativos que normalizam URLs não confiáveis antes de verificações de allowlist de host, validação de redirecionamento ou roteamento de requisições externas podem ser direcionados para uma autoridade diferente da especificada na entrada.

As funções `normalize()` e `equal()` decodificam separadores de caminho e segmentos de ponto percentualmente codificados antes de aplicar a remoção de segmentos de ponto. Isso faz com que dados de caminho codificados sejam tratados como barras reais e referências a diretórios pai, permitindo que URIs distintas colapsem no mesmo caminho normalizado. Consequentemente, aplicações que utilizam essas funções para impor políticas baseadas em caminho em URLs controladas por atacantes podem ser burladas, pois um caminho que parece confinado sob um prefixo permitido pode ser normalizado para um local diferente.

Existe um problema onde os resultados da seleção do serializador são armazenados em cache usando o cabeçalho `Accept` da requisição como chave, sem um limite de tamanho ou política de despejo. Um cliente remoto não autenticado pode enviar inúmeras variantes distintas, porém correspondentes, do cabeçalho `Accept`, fazendo com que o cache cresça de forma ilimitada. Isso pode levar ao esgotamento do heap do Node.js e resultar na interrupção do processo, causando uma Negação de Serviço (DoS).

Quando `trustProxy` é configurado com uma função de confiança restritiva, como um IP específico, uma sub-rede, uma contagem de saltos ou uma função personalizada, os getters `request.protocol` e `request.host` leem os cabeçalhos `X-Forwarded-Proto` e `X-Forwarded-Host` de qualquer conexão, incluindo aquelas de IPs não confiáveis. Isso permite que um atacante que se conecte diretamente ao Fastify ignore o proxy e falsifique o protocolo e o host vistos pela aplicação. Este problema afeta aplicações que dependem de `request.protocol` ou `request.host` para decisões críticas de segurança, incluindo a imposição de HTTPS, flags de cookies seguros, verificações de origem CSRF, construção de URL e roteamento baseado em host.

This is an uncontrolled resource consumption issue that can lead to a Denial of Service (DoS). When the `interceptors.deduplicate()` function is enabled in vulnerable versions, response data for deduplicated requests can accumulate in memory for downstream handlers. An attacker-controlled or untrusted upstream endpoint can exploit this with large or chunked responses and concurrent identical requests, causing high memory usage and potential Out Of Memory (OOM) process termination. Impacted users are applications that utilize Undici’s deduplication interceptor against endpoints that may produce large or long-lived response bodies. The issue is addressed by changing the deduplication behavior to stream response chunks to downstream handlers as they arrive, instead of accumulating the full body, and by preventing late deduplication when body streaming has already started.

The undici WebSocket client is susceptible to a denial-of-service attack because of insufficient validation of the `server max window bits` parameter within the permessage-deflate extension. When a WebSocket client establishes a connection with a server, it automatically signals support for permessage-deflate compression. A malicious server can respond with a `server max window bits` value that is outside the valid range for zlib (8-15). Subsequently, when the server transmits a compressed frame, the client attempts to instantiate a zlib InflateRaw object using this invalid `windowBits` value, leading to a synchronous RangeError that is not handled, ultimately causing the Node.js process to terminate. The issue arises because the `isValidClientWindowBits()` function only verifies that the value consists of ASCII digits, without ensuring it falls within the acceptable range. Additionally, the call to `createInflateRaw()` is not enclosed in a try-catch block, and the resulting exception propagates through the call stack, crashing the process.

A server can respond with a WebSocket frame utilizing the 64-bit length format and an excessively large length value. The `ByteParser` component within undici experiences an integer overflow during internal mathematical operations, leading to an invalid state and ultimately causing a fatal `TypeError` that terminates the process.

Undici is susceptible to inconsistent interpretation of HTTP requests, specifically HTTP Request/Response Smuggling. The issue arises when duplicate HTTP `Content-Length` headers are provided in an array format, using case-variant names (e.g., `Content-Length` and `content-length`). This results in malformed HTTP/1.1 requests containing conflicting `Content-Length` values. Applications utilizing `undici.request()`, `undici.Client`, or similar low-level APIs with headers passed as flat arrays are impacted, as are applications that accept user-controlled header names without case-normalization. Potential consequences include Denial of Service, where strict HTTP parsers reject requests with duplicate headers, and HTTP Request Smuggling, which can lead to ACL bypass, cache poisoning, or credential hijacking in deployments with inconsistent header interpretation between intermediaries and backends.

The undici WebSocket client is susceptible to a denial-of-service condition due to unrestricted memory usage during permessage-deflate decompression. When a WebSocket connection utilizes the permessage-deflate extension, the client decompresses incoming compressed frames without enforcing any limits on the decompressed data size. A malicious WebSocket server can transmit a small compressed frame, known as a "decompression bomb," which expands to a substantial size in memory. This can lead to the Node.js process exhausting available memory, resulting in a crash or unresponsiveness. The issue resides within the `PerMessageDeflate.decompress()` method, which accumulates decompressed data in memory without verifying if the total size exceeds a safe limit.

The issue arises when an application passes user-controlled input to the `upgrade` option of the `client.request()` function. This allows an attacker to inject CRLF (Carriage Return Line Feed) sequences (`r `) to inject arbitrary HTTP headers or prematurely terminate HTTP requests, potentially smuggling raw data to non-HTTP services like Redis, Memcached, and Elasticsearch. The root cause is that undici writes the `upgrade` value directly to the socket without validating for invalid header characters. The vulnerable code is located in `lib/dispatcher/client-h1.js` at line 1121.

O Fastify valida incorretamente os cabeçalhos `Content-Type`, aceitando cabeçalhos malformados com caracteres adicionais após o token do subtipo, o que viola a RFC 9110. Especificamente, uma requisição com um `Content-Type` como 'application/json garbage' pode ser processada em vez de ser rejeitada com um erro 415 Unsupported Media Type. Ao utilizar parsers de content-type baseados em regex, o valor malformado é comparado com os parsers registrados, potencialmente direcionando a requisição para um parser não pretendido. Isso permite que um atacante contorne a validação de conteúdo e faça com que o servidor processe requisições com tipos de conteúdo inválidos.

Existe uma falha no Multer, um middleware do Node.js utilizado para processar `multipart/form-data`. Este problema pode ser explorado para causar uma Negação de Serviço (DoS) ao enviar solicitações especialmente elaboradas, o que pode levar a um estouro de pilha.

O software é suscetível a uma condição de negação de serviço decorrente do processamento ineficiente de corpos de requisição codificados em URL contendo um grande número de parâmetros. Um atacante pode explorar isso enviando requisições com milhares de parâmetros dentro do limite de tamanho de requisição de 100KB, resultando em aumento do consumo de CPU e memória. Isso pode causar degradação do serviço ou indisponibilidade quando submetido a tráfego malicioso contínuo.

Nome do Software Vulnerável e Versões Afetadas Lodash versões 4.0.0 a 4.17.22 Descrição As versões 4.0.0 a 4.17.22 do Lodash são vulneráveis à poluição de protótipo nas funções ` .unset` e ` .omit`. Um atacante pode explorar caminhos elaborados para disparar a exclusão de métodos dos protótipos globais. O problema permite a exclusão de propriedades, mas não permite a modificação do comportamento original dessas propriedades. Recomendações Atualize para a versão 4.17.23 do Lodash ou posterior.