Matteo Collina

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.

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.

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.

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.

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.

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.

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.

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.

**Nome do software vulnerável e versões afetadas: versões do fastify-csrf anteriores à 3.0.0 Descrição: A vulnerabilidade afeta o pacote fastify-csrf, no qual o cookie gerado utiliza configurações padrão inseguras e não possui o sinalizador httpOnly, conforme observado em `cookieOpts: { path: ‘/’, sameSite: true }`. Além disso, o token CSRF está disponível no parâmetro de consulta GET. Esse conjunto de problemas compromete a capacidade do pacote de fornecer proteção contra CSRF. Recomendações: Para versões anteriores à 3.0.0, atualize para a versão 3.0.0 ou posterior para resolver o problema. Como solução alternativa temporária, considere definir o sinalizador httpOnly no cookie e restringir o acesso ao token CSRF no parâmetro de consulta GET.

O problema está relacionado a um erro no tratamento dos nomes dos cabeçalhos HTTP, que pode ser explorado por um invasor remoto para causar uma negação de serviço (DoS). Isso pode fazer com que o servidor fique incapaz de aceitar novas conexões devido ao atraso no envio das solicitações.

The issue is related to improper authorization, where aedes does not respect its own authorization rules when a client sets a `Last Will`. This can lead to publishing a Last Will and Testament (LWT) in a channel even when the client is not authorized.