Matteo Collina

The `normalize()` function decoded percent-encoded authority delimiters within the host component and re-emitted them as raw delimiters during serialization. This allows a host combining an allowed domain, an encoded at-sign, and a different domain to be re-emitted with the at-sign as a raw userinfo separator, effectively changing the URI's authority to the second domain. Applications that normalize untrusted URLs before performing host allowlist checks, redirect validation, or outbound request routing can be steered to an authority different from the one specified in the input.

The `normalize()` and `equal()` functions decode percent-encoded path separators and dot segments before performing dot-segment removal. This causes encoded path data to be treated as actual slashes and parent-directory references, allowing distinct URIs to collapse into the same normalized path. Consequently, applications using these functions to enforce path-based policies on attacker-controlled URLs may be bypassed, as a path appearing confined under an allowed prefix can normalize to a different location.

When `trustProxy` is configured with a restrictive trust function, such as a specific IP, a subnet, a hop count, or a custom function, the `request.protocol` and `request.host` getters read `X-Forwarded-Proto` and `X-Forwarded-Host` headers from any connection, including those from untrusted IPs. This allows an attacker connecting directly to Fastify to bypass the proxy and spoof the protocol and host seen by the application. This issue impacts applications that rely on `request.protocol` or `request.host` for security-critical decisions, including HTTPS enforcement, secure cookie flags, CSRF origin checks, URL construction, and host-based routing.

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.

Fastify incorrectly validates `Content-Type` headers, accepting malformed headers with trailing characters after the subtype token, which violates RFC 9110. Specifically, a request with a `Content-Type` like 'application/json garbage' may be processed instead of being rejected with a 415 Unsupported Media Type error. When using regex-based content-type parsers, the malformed value is matched against registered parsers, potentially routing the request to an unintended parser. This allows an attacker to bypass content validation and have the server process requests with invalid content types.

Name of the Vulnerable Software and Affected Versions: fastify-csrf versions prior to 3.0.0 Description: The issue affects the fastify-csrf package, where the generated cookie uses insecure defaults and lacks the httpOnly flag, as seen in `cookieOpts: { path: '/', sameSite: true }`. Additionally, the CSRF token is available in the GET query parameter. This set of issues compromises the package's ability to provide CSRF protection. Recommendations: For versions prior to 3.0.0, update to version 3.0.0 or later to resolve the issue. As a temporary workaround, consider setting the httpOnly flag on the cookie and restricting access to the CSRF token in the GET query parameter.

The issue is related to an error in handling HTTP header names, which can be exploited by a remote attacker to cause a denial of service (DoS). This can make the server unable to accept new connections due to delayed requests submission.

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.