undici vulnerable to Denial of Service via orphaned RetryHandler response body

undici vulnerable to downstream response splitting via retry interceptor

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 default WebSocket connection sends no subprotocol, but if the server's 101 response includes a Sec-WebSocket-Protocol header, undici dereferences a null value while checking it against the requested list and throws an uncaught TypeError. Because that code runs inside a microtask with no surrounding error handling, the exception propagates and terminates the process under Node's default behavior, instead of gracefully failing the connection as required by the WebSocket protocol. Any application that opens a WebSocket to an attacker-controlled or compromised server, or over a plaintext connection subject to a machine-in-the-middle, can be crashed remotely without authentication in the default configuration. This affects undici versions from 6.7.0 up to 6.28.1, from 7.0.0 up to 7.29.1, and from 8.0.0 up to 8.10.2. Users should upgrade to undici 6.28.1, 7.29.1, or 8.10.2.

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 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.

undici's dump interceptor reads and discards a response body up to a configurable maximum size. When a response declares a Content-Length that exceeds the maximum, the interceptor aborts cleanly, but when a response has no Content-Length and is chunked, the interceptor instead signals completion early once the accumulated size reaches the maximum, without pausing or aborting the request. Because the underlying parser keeps delivering body bytes, a second completion signal fires and trips an internal assertion, which aborts the request and tears down the connection. The application is left observing a misleading successful status with an empty or truncated body while the connection has actually been disconnected. This affects undici versions from 7.1.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. 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 8.10.0 omits the destination origin from the cache and request-deduplication keys when the cache or deduplicate interceptor is composed directly onto a Client or Pool. Because the internal cache key falls back to an empty origin string, a cacheable or in-flight response from one upstream origin is returned for a request to a different, trusted origin whenever the method, path, and relevant headers match, which permits cross-origin information disclosure and persistent cache poisoning. The reporter demonstrated a full authentication bypass in which a JWT signed with an attacker-controlled key was accepted as belonging to a trusted issuer, and the trusted origin was never contacted. This is a regression introduced in 8.10.0 and affects undici versions from 8.10.0 up to 8.10.2. Applications using an Agent, which carries the origin in its dispatch options, are not affected. Users should upgrade to undici 8.10.2.

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 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. This affects undici versions from 6.25.0 up to 6.28.1, from 7.28.0 up to 7.29.1, and from 8.1.0 up to 8.10.2. Users should upgrade to undici 6.28.1, 7.29.1, or 8.10.2.

A flaw in Node.js Permission Model enforcement allows traceevents.createTracing().enable() Writes Trace Logs Outside --allow-fs-write. This can lead to confidentiality impact or bypass of the intended security boundary under affected configurations. This vulnerability affects Node.js 22.x, 24.x, and 26.x.

A flaw in Node.js Permission Model enforcement can over-grant filesystem access across radix-tree prefix boundaries.

Under --permission, an attacker who is granted access to one path can abuse boundary handling to read from or write to paths outside the intended filesystem allowlist.

This vulnerability affects Node.js main, 22.x, 24.x, and 26.x.

A flaw in Node.js HTTPS Agent connection reuse can cause PFX object-array key collisions, allowing mutual TLS (mTLS) client identities to be reused across requests configured with different client certificates. This vulnerability affects Node.js 26.x, 24.x, and 22.x.

Impact

When an application passes a duck-typed blob-like body to undici's HTTP/1.1 dispatcher (via request(), stream(), pipeline(), or dispatch()) with a .type derived from untrusted input, an attacker can inject CRLF sequences (\r\n) to append arbitrary HTTP headers and potentially smuggle a second request past the upstream.

The vulnerable branch in lib/dispatcher/client-h1.js pushes body.type directly into the outgoing headers with no validation, while every other header path in undici goes through isValidHeaderValue():

javascript } else if (util.isBlobLike(body) && request.contentType == null && body.type) { headers.push('content-type', body.type) // bypasses isValidHeaderValue() }

The bug requires a hand-rolled duck-typed blob object or a Blob subclass with a controlled .type. Native Blob is safe because its constructor strips CRLF from .type. fetch() is unaffected because it validates via the Headers class. Ecosystem consumers that build duck-typed blob shapes from user input include form-data-encoder, formdata-polyfill, and formdata-node.

Same defect class as CVE-2022-35948 (explicit content-type sink, fixed in undici 5.8.2) and CVE-2026-1527 (upgrade option sink, fixed in 6.24.0 / 7.24.0), both closed by adding isValidHeaderValue() on their respective sinks. This branch was missed.

Patches

Patched in undici v6.28.0, v7.29.0, and v8.9.0. Users should upgrade to one of these versions or later.

Workarounds

- Set an explicit, validated content-type header on the request options (skips the vulnerable branch). - Use a native Blob (or fetch-blob) instead of a hand-rolled duck-typed object. - Reject control characters in the MIME type before assigning it to .type. - Use fetch() instead of the non-fetch APIs.

Impact

Undici's cache interceptor mishandles optional whitespace (OWS) placed around the = of a qualified no-cache or private Cache-Control directive, such as no-cache ="authorization" (OWS before =) or no-cache= "authorization" (OWS after =). The parser either drops the directive entirely or stores a field name with literal quote characters, so the downstream cache decisions do not recognize the qualification and the response is stored.

In shared-cache mode, this allows a response containing one user's authenticated data to be served from cache to a subsequent caller, including an unauthenticated caller, when both requests resolve to the same cache key. The impact class is identical to CVE-2026-9678 (GHSA-pr7r-676h-xcf6); this advisory covers the whitespace-around-= bypass that the earlier fix did not normalize.

Affected applications are those that explicitly enable the cache interceptor (interceptors.cache()) in shared mode, forward Authorization headers upstream, and receive cacheable responses with qualified private or no-cache directives whose field-name list is padded with OWS around the =.

Patches

Upgrade to undici v7.29.0 or v8.9.0.

Workarounds

If upgrade is not immediately possible, disable shared-cache mode for traffic that includes Authorization headers, avoid caching responses to authenticated requests, or add Vary: Authorization upstream.

Impact

Undici's interceptors.retry() can deliver a response whose body length does not match the Content-Length header exposed to the application after a retry or resume of a partial response. Applications that use interceptors.retry() and forward upstream response headers and bodies downstream, for example proxy or gateway applications, may emit an invalid HTTP response with a stale Content-Length header. This can lead to downstream response desynchronization, connection hangs, or response corruption in clients or intermediaries that rely on the forwarded framing metadata.

A malicious or faulty upstream can respond to a range request with a 206 Partial Content response such as:

http Content-Range: bytes 0-99/300 Content-Length: 300

and then send only 99 bytes before closing the socket. interceptors.retry() can then retry with Range: bytes=99-99, receive the final byte, and deliver a 100-byte body to the application while the response headers still contain Content-Length: 300 from the first response.

The bug requires interceptors.retry() to be enabled, an upstream that returns a partial response with a mismatched framing header, and a downstream forwarder that does not remove or recalculate Content-Length.

Patches

Patched in undici v6.28.0, v7.29.0, and v8.9.0. Users should upgrade to one of these versions or later.

Workarounds

- Disable interceptors.retry() for untrusted upstreams. - Remove or recalculate Content-Length before forwarding a response body assembled or transformed by Undici.

Impact

The setCookie function has two attribute injection paths. validateCookieDomain does not reject semicolons (validateCookiePath already does at 0x3B), so a domain value like example.com; SameSite=None lands verbatim as Domain=example.com; SameSite=None. The unparsed array's loop only checks each entry contains = and does not sanitize values, so an entry like X-Custom=val; HttpOnly lands unchanged, injecting HttpOnly without the caller setting cookie.httpOnly = true.

Applications that pass user-controlled input to these fields, typically multi-tenant or reverse-proxy servers that scope session cookies to a tenant-supplied domain, can have SameSite CSRF protections bypassed, Secure or HttpOnly forced or stripped, or the intended SameSite tier overridden.

Patches

Patched in undici v6.28.0, v7.29.0, and v8.9.0.

Workarounds

- Sanitize domain values against the RFC 1034 letter-digit-hyphen set before passing to setCookie. - Do not pass user-controlled data to the unparsed field.

Summary

Two issues in undici's cache interceptor, both fixed by the same patch on lib/util/cache.js:

1. Shared-cache disclosure: Responses with malformed qualified Cache-Control: private directives such as private="" or private="," can be incorrectly stored in the default shared cache, then served to a later caller with the same cache key. 2. Parse-time crash: Mixed unqualified-and-qualified private directives in the same header (such as public, max-age=60, private, private="hdr") cause an uncaught TypeError in the cache-control parser, terminating the request.

Impact

Shared-cache disclosure

Applications using interceptors.cache() in shared mode may cache a user-specific response and serve it to a later caller with the same cache key. This can disclose private response bodies and headers, including Set-Cookie.

Required conditions:

- the cache interceptor is enabled in shared mode, including the default configuration; - an upstream returns a malformed directive such as Cache-Control: public, max-age=300, private=""; - another request later matches the same cache key, without a separating Vary header.

Parse-time crash

Applications using interceptors.cache() against an upstream that returns a Cache-Control header combining unqualified private with qualified private="..." see an uncaught TypeError: output.private.concat is not a function during response handling. The request rejects; depending on the consumer's error handling, the process may exit.

Details

private="" is parsed as { private: [''] }. The shared-cache guard only rejects private === true, so the response can be stored. When served from cache, the previous user's body and headers may be returned to a different user.

For the crash variant, an unqualified private directive sets output.private = true, then a subsequent qualified private="hdr" directive attempts output.private.concat(['hdr']), which throws because boolean has no concat method.

The patch routes the qualified-directive path through a shared helper that normalizes empty-after-trim arrays to true and preserves existing true values, closing both vectors.

Patches

Upgrade to undici 7.29.0 or 8.9.0. Both releases fix the qualified private directive handling that caused the shared-cache storage and the parser crash.

Workarounds

Until patched, avoid shared interceptors.cache() for user-specific responses, use type: 'private', or disable caching for affected origins.

Credit

Disclosure variant reported by @h0rk1p via HackerOne report #3817497.

A flaw in Node.js TLS hostname handling can cause Embedded-nul hostnames can lead to silent authority rebinding due to c-string truncation in resolver bindings.

This vulnerability affects all supported release lines: Node.js 22, Node.js 24, and Node.js 26.

A flaw in Node.js WebCrypto implementation can crash the process if the input of subtle.encrypt() is a multiple of 2GiB.

This vulnerability affects all supported release lines: Node.js 22, Node.js 24, and Node.js 26.

A inconsistency in Node.js hostname matching can cause a trust-policy bypass in multi-context mTLS setups.

This vulnerability affects all supported release lines: Node.js 22, Node.js 24, and Node.js 26.

A flaw in Node.js HTTP/2 client allows a server to send an unlimited number of ORIGIN frames, which could lead to an Out of Memory error on the client.

This vulnerability affects all supported release lines: Node.js 22, Node.js 24, and Node.js 26.

A flaw in Node.js TLS host verification can cause an attacker to bypass certification validation.

This vulnerability affects all supported release lines: Node.js 22, Node.js 24, and Node.js 26.

A flaw in Node.js Permission API can cause a local server to be started (via a Unix domain socket), even without the --allow-net permission. This vulnerability affects one supported release line: Node.js 26.

A flaw in Node.js Permission API can cause a file metadata to be modified even on a path that was set as read-only with e.g. --allow-fs-read.

This vulnerability affects all supported release lines: Node.js 22, Node.js 24, and Node.js 26.

A flaw in Node.js proxy tunnel error handling could expose proxy credentials in ERRPROXYTUNNEL error messages.

When proxy credentials are embedded in the proxy URL, they may be exposed through error handling paths and captured by logs, diagnostics, or other error consumers.

This vulnerability affects all supported release lines: Node.js 22, Node.js 24, and Node.js 26.

A flaw in Node.js TLS hostname handling can cause Node.js unicode dot separator handling can lead to tls wildcard-depth authentication bypass due to resolver and verifier hostname normalization mismat.

This can lead to confidentiality impact or bypass of the intended security boundary under affected configurations.

This vulnerability affects all supported release lines: Node.js 22, Node.js 24, and Node.js 26.

A flaw in Node.js HTTP Agent can cause a client to accept as valid a response that is send before the client has sent the request. This vulnerability affects all supported release lines: Node.js 22, Node.js 24, and Node.js 26.

A flaw in Node.js HTTP/2 server API can cause servers to keep accepting data even after sending a GOAWAY frame. This vulnerability affects two supported release lines: Node.js 22 and Node.js 24.