Ulises Gascón

The logging middleware fails to neutralize control characters when the `:remote-user` token extracts the Basic auth username from the Authorization request header. An unauthenticated attacker can send a crafted Authorization Basic header containing Carriage Return (CR) or Line Feed (LF) bytes to inject forged log lines. This breaks the one-request-per-line structure of access logs, enabling log forgery against downstream log consumers. The issue affects the built-in combined, common, default, and short formats, as well as any custom format referencing `:remote-user`.

A denial of service occurs due to an uncaught exception during the parsing of `multipart/form-data` requests. When a request contains a `Content-Disposition` header with a `filename*` parameter featuring malformed percent-encoding, the parser calls the `decodeURI()` function without a try/catch block. This results in a `URIError` that crashes the process, affecting any service that accepts multipart uploads via this library.

A denial of service occurs when a multipart/form-data request is sent with a field name that collides with an inherited Object.prototype property, such as ` proto `, `constructor`, or `toString`. This causes the parser to invoke the `.push()` function on the inherited prototype value instead of an array, resulting in a TypeError that triggers an uncaught exception and crashes the process. This issue affects any service that accepts multipart uploads via multiparty.

A denial of service issue exists due to regular expression backtracking in the Content-Disposition filename parameter parser. A crafted multipart upload containing a long header value can cause regex matching to take several seconds, which blocks the event loop. This affects any service that accepts multipart uploads using this library.

Cross-origin source code exposure occurs when serving over a non-potentially trustworthy origin, such as plain HTTP. The issue arises because the previous fix relied on `Sec-Fetch-Mode` and `Sec-Fetch-Site` request headers, which browsers omit for non-trustworthy origins. This allows a malicious site to load the bundled source as a script and read it across origins. An attacker controlling a website visited by a developer can recover the application source code if the server runs over HTTP at a guessable host and port. Chromium-based browsers from Chrome 142 onward are not affected due to local network access restrictions.

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.

An issue exists where serializer-selection results are cached using the request `Accept` header as a key without a size limit or eviction policy. A remote unauthenticated client can send numerous distinct but matching `Accept` header variants, causing the cache to grow unbounded. This can lead to the exhaustion of the Node.js heap and result in a process crash, causing a Denial of Service (DoS).

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.

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.

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.

A flaw exists in Multer, a node.js middleware used for processing `multipart/form-data`. This issue can be exploited to cause a Denial of Service (DoS) by submitting specially crafted requests, which may lead to a stack overflow.

The software is susceptible to a denial of service condition resulting from inefficient processing of URL-encoded request bodies containing a large number of parameters. An attacker can exploit this by sending requests with thousands of parameters within the 100KB request size limit, leading to increased CPU and memory consumption. This can cause service degradation or outages when subjected to continuous malicious traffic.

Lodash versions 4.0.0 through 4.17.22 are susceptible to prototype pollution within the ` .unset` and ` .omit` functions. An attacker can leverage crafted paths to trigger the deletion of methods from global prototypes. The issue allows for property deletion but does not permit modification of the original behavior of those properties.