undici vulnerabilities

undici's decompress interceptor decompresses response bodies according to the untrusted Content-Encoding header. While the number of content-encoding layers is capped, the total decompressed output size is unbounded and there is no configuration option to limit it. A malicious or faulty upstream can therefore return a small compressed payload, a compression bomb, that expands to hundreds of megabytes or more in client memory, an asymmetric resource consumption that can exhaust memory and crash the process. This affects undici versions from 7.15.0 up to 7.29.1 and from 8.0.0 up to 8.10.2. Users should upgrade to undici 7.29.1 or 8.10.2.

undici's WebSocket client crashes the whole Node.js process during the opening handshake when a server responds with a subprotocol that the client never requested. A null dereference causes an uncaught TypeError that terminates the process.

In the undici library before version 6.28.1, from 7.0.0 up to 7.29.1, and from 8.0.0 up to 8.10.2, the retry interceptor can append the body of a ranged retry response to bytes already delivered from an earlier partial response while still presenting the original response's status and headers. This can cause the response body to be longer than the Content-Length observed by the application. An application that relays such a response to a downstream HTTP/1.1 peer without normalizing the framing can emit a body that exceeds the forwarded Content-Length, and the excess bytes can be interpreted as the start of a following response, enabling response splitting or desynchronization.

In the undici library versions from 7.11.0 up to 7.29.1 and from 8.0.0 up to 8.10.2, the retry handler can leave an already-exposed response body pending forever. When a server returns a response with Content-Length, sends only part of the body, and closes the connection, the retry handler retries the request. If the retry returns a non-retryable status such as 400, the handler forwards the new response but the original response body is never ended or destroyed, causing reads on that body to never settle and the body timeout not to fire.

undici 8.10.0 omits the destination origin from cache and request-deduplication keys when the cache or deduplicate interceptor is composed directly onto a Client or Pool. This allows cross-origin information disclosure and persistent cache poisoning. Affects versions 8.10.0 to 8.10.2; applications using an Agent are not affected.

undici bundles a WebSocket client whose permessage-deflate size-limit cleanup removes all listeners from the internal zlib inflate stream, including its error listener, while that stream can still emit. When a remote peer sends a compressed payload that crosses the built-in 128 MiB decompressed-payload limit and then contains a malformed DEFLATE byte, the inflate stream emits a data error with no listener attached, which Node.js treats as a fatal unhandled error and terminates the entire process. Exploitation is remote and unauthenticated, requires no application mistake, and is asymmetric, since roughly 130 KB on the wire expands past the limit and crashes the process, and reconnecting can repeat the crash.

undici's experimental WebSocketStream client crashes the whole Node.js process when a remote peer closes the TCP connection without a WebSocket close handshake. On an unclean close the internal socket-close handler calls abort on the writable stream unconditionally and discards the returned promise, but per the WHATWG Streams standard aborting a locked writable returns a promise that rejects with a TypeError. Because the application holds a writer on that writable, which is the only way to write, the rejection is never observed and Node's default unhandled-rejection behavior terminates the process. An untrusted server can therefore crash a client with a single abrupt disconnect, with no authentication and no application mistake. This affects undici versions from 7.0.0 up to 7.29.1 and from 8.0.0 up to 8.10.2. Users should upgrade to undici 7.29.1 or 8.10.2.

undici's cache interceptor documents that only safe HTTP methods are cached, but its logic to skip caching is built by subtracting the configured methods from the set of safe methods, so an unsafe method such as POST, PUT, or DELETE is never placed in the skip list and instead falls through to the full cache-read path. The response-storage gate also lacked a method check, so a response to an unsafe request that is heuristically cacheable or carries an explicit Cache-Control directive is stored and later replayed from cache. Because response headers from a remote origin are untrusted, an origin can answer once with a cacheable status and then have the client's own subsequent state-changing requests to that path served from the stale cache entry without ever reaching the origin, an integrity failure that occurs under the interceptor's default configuration. This affects undici versions from 7.0.0 up to 7.29.1 and from 8.0.0 up to 8.10.2. Users should upgrade to undici 7.29.1 or 8.10.2.

undici's BalancedPool constructor passes its entire options object through an internal deep-clone that serializes and reparses the value as JSON. Because JSON cannot represent functions, any function-valued TLS option, such as a caller-supplied checkServerIdentity callback or a custom connector inside the connect option, is silently discarded before it reaches the TLS layer. As a result a peer whose certificate the application's custom checkServerIdentity was written to reject, but which still passes Node's default hostname and chain checks, is accepted when reached through BalancedPool. The Client, Pool, and Agent dispatchers are not affected because they extract the connect and tls options before cloning. This affects undici versions from 7.24.1 up to 7.29.1 and from 8.0.0 up to 8.10.2, and only when the application supplies a function-valued connect or tls option to BalancedPool.

The dump interceptor in undici mishandles chunked responses without Content-Length when the body size exceeds the maximum limit. Instead of pausing or aborting, it signals early completion, causing a second completion signal that triggers an internal assertion and tears down the connection. The application observes a misleading success status with an empty or truncated body while the connection is actually disconnected.

undici's cache interceptor does not handle the Set-Cookie response header anywhere in its cache path, so it neither refuses to store nor strips that header. In shared cache mode, which is the default, an otherwise cacheable response that carries a Set-Cookie header, for example one marked with a public and max-age directive, is stored and then re-served to a later caller that matches the same cache key. As a result one caller's cookie is disclosed to a different caller, and an untrusted server can inject cookies into cached responses served to all subsequent callers. This violates the requirement that a shared cache must not store cookies. This affects undici versions from 7.0.0 up to 7.29.1 and from 8.0.0 up to 8.10.2. Users should upgrade to undici 7.29.1 or 8.10.2.

In undici before versions 6.28.0, 7.29.0, and 8.9.0, the 'type' property of hand-rolled blob-like request bodies is not validated. An attacker can inject CRLF sequences and append arbitrary HTTP headers, potentially smuggling a second request.

In undici before versions 7.29.0 and 8.9.0, the cache interceptor mishandles optional whitespace around the equals sign in Cache-Control directives. This can cause authenticated user data to be cached and served to other users.

In undici before versions 6.28.0, 7.29.0, and 8.9.0, the retry interceptor can deliver a response whose body length does not match the Content-Length header, potentially leading to response desynchronization, connection hangs, or response corruption.

The setCookie function in undici before versions 6.28.0, 7.29.0, and 8.9.0 does not fully sanitize cookie attributes. Domain values are not checked for semicolons, and unparsed array entries are not sanitized, allowing attacker-influenced input to inject additional attributes like SameSite, HttpOnly, or Secure without the caller's knowledge.

In undici before versions 7.29.0 and 8.9.0, the cache interceptor mishandles malformed Cache-Control private directives. A response with a private directive set to an empty value can be stored in the shared cache and served to other users, disclosing private data. Additionally, combining an unqualified and qualified private directive causes a TypeError that can crash the process.

A vulnerability in the undici library causes the requestTls option to be silently dropped when using ProxyAgent with a SOCKS5 proxy. The HTTPS connection through the SOCKS5 tunnel falls back to Node's default trust store instead of user-configured settings.

Undici's cookie parser (parseSetCookie) decodes cookie values, which can lead to HTTP response header injection. Applications that forward parsed cookie values into response headers become vulnerable to attacks such as session fixation or malicious redirects.

A vulnerability in Undici allows incorrect classification of responses as cacheable when Cache-Control headers contain whitespace. This can lead to authenticated user data being served to another user from the cache.

In the undici library, a vulnerability allows Socks5ProxyAgent to reuse a single connection pool across different origins without verifying origin match. This causes cross-origin request routing, credential leakage, and potential HTTPS downgrade to HTTP.

A vulnerability in undici allows the acceptance of incorrect SameSite attribute values in the Set-Cookie header, potentially leading to a weakening of the cookie's SameSite policy. Instead of the required case-insensitive exact match, values containing 'Strict', 'Lax', or 'None' as substrings are accepted.

The undici WebSocket client does not limit the number of message fragments, allowing a malicious server to send many small continuation frames. This causes unbounded memory growth and denial of service (DoS).

The undici WebSocket client is vulnerable to a denial-of-service attack due to improper validation of the server_max_window_bits parameter in the permessage-deflate extension. A malicious server can send an out-of-range value (outside 8-15), causing an unhandled RangeError exception and immediate Node.js process termination.

A vulnerability in the undici library allows a server to send a WebSocket frame with a 64-bit length field containing an extremely large value. The ByteParser overflows internal math, enters an invalid state, and throws a fatal TypeError that terminates the process.

The undici WebSocket client is vulnerable to a denial-of-service attack via unbounded memory consumption during permessage-deflate decompression. A malicious WebSocket server can send a small compressed frame (a 'decompression bomb') that expands to an extremely large size in memory, causing the Node.js process to exhaust available memory and crash or become unresponsive.