Impact
undici's decompress interceptor forwards decompressed response data to the downstream handler from zlib stream event callbacks without catching exceptions those callbacks may throw. undici's engine converts a synchronous throw from a downstream handler into a per-request failure, but that protection is not in place when the throw happens asynchronously from a zlib callback. As a result, a downstream handler that throws by design, for example the built-in dump interceptor which throws when a response exceeds its maxSize, escapes as an uncaught exception and terminates the Node.js process.
A malicious or compromised HTTP server can crash any client that composes the decompress interceptor with dump (or another response handler that throws), by returning a small compressed body that decompresses to more than the configured limit. The compressed bytes on the wire are tiny, so only the decompressed size matters. If the application keeps the process alive with a global uncaught-exception handler, the affected request instead hangs until the body timeout.
Patches
Upgrade to undici 7.30.1 or 8.12.2.
Workarounds
Avoid composing the decompress interceptor with a response handler that throws during response processing (such as dump with a maxSize) until upgrading.
Impact
undici crashes the client process when a TLS 1.2 server renegotiates after the connection is established and presents a different, CA-trusted certificate whose hostname does not match the requested host. Node.js re-runs hostname verification on the renegotiated handshake and destroys the socket with ERRTLSCERTALTNAMEINVALID. undici's established socket error handler asserted that this error code could never occur, so the peer-controlled error became an uncaught AssertionError that terminates the Node.js process. Both the HTTP/1.1 and HTTP/2 paths are affected.
A malicious or compromised HTTPS endpoint reached through undici or the global fetch() can crash the client with a single server-initiated renegotiation, taking down all in-flight requests and background work in the process. Only TLS 1.2 is affected, because TLS 1.3 does not support renegotiation. Exploitation does not require a CA compromise: the attacker controls the endpoint and can present two ordinary valid certificates, the first matching the requested URL and the second intentionally not matching it.
Patches
Upgrade to undici 6.29.1, 7.30.1, or 8.12.2.
Workarounds
Restrict outbound connections to TLS 1.3, for example by setting connect: { minVersion: 'TLSv1.3', maxVersion: 'TLSv1.3' } on the client or agent, so that renegotiation cannot occur, when the target endpoints support TLS 1.3.
Impact
undici's experimental WebSocket client (enabled by default via allowH2: true) crashes the Node.js process when it connects to a malicious server over HTTP/2. If the server answers the WebSocket upgrade with a response that fails handshake validation, undici aborts the request, but the abort is a no-op because the request is already marked completed, so the underlying ClientHttp2Stream is left open with no error listener. When the server then destroys the connection, the orphaned stream emits an unhandled error and the process exits. A remote, unauthenticated server can therefore deny service to any client that opens a WebSocket to it over HTTP/2. undici 8.11.0 and 8.11.1 are affected; the regression was introduced in 8.11.0.
Patches
Upgrade to 8.11.2.
Workarounds
Set allowH2: false to disable HTTP/2 for WebSocket connections, or avoid opening WebSocket connections to untrusted servers, until upgrading.
Impact
undici's EventSource client can be driven to exhaust process memory by a malicious or compromised Server-Sent Events peer. By sending millions of tiny completed data: fields with no blank event separator, or a single unfinished line split across many chunks, the parser retains a growing amount of per-field and per-chunk state. The byte-based maxEventSize and maxResponseSize limits do not bound that retained state, and maxResponseSize is enforced on the compressed body before decompression, so a small compressed response can expand into enough retained memory to terminate the process. The application only needs to maintain an EventSource connection to an untrusted peer, which controls only the response. Availability is the only impact.
Patches
Upgrade to 6.29.1, 7.30.1, or 8.12.2, which bound the retained EventSource parser state (the number of data fields and buffered chunks, the unfinished-line length, and per-field byte totals) independently of the byte limits.
Workarounds
None.
Impact
undici's fetch() crashes the Node.js process when a malicious server returns a response with more than five content codings and closes the connection before sending the body. undici rejects such responses (a content-encoding limit), but it created the internal response stream before that check and returned without attaching an error listener or aborting the request. The early close then surfaces a content-length mismatch on that orphaned internal stream, which Node.js treats as an unhandled error and terminates the process. A remote, unauthenticated server can trigger this with a single response, even when the application correctly catches the fetch() rejection. undici 6.x, 7.x, and 8.x are affected.
Patches
Upgrade to 6.29.1, 7.30.1, or 8.12.2. undici now validates the content-encoding chain before creating the internal body stream and aborts the response when the limit is exceeded, so no error can surface on an orphaned stream.
Workarounds
None.
Impact
When an originless Agent composes the redirect and cache interceptors as compose(redirect(), cache()) with a shared cache (type: 'shared'), the cache builds its key from the original request URL before the redirect handler changes the origin. The response produced after a redirect is then stored under the original key, even when the redirect crossed to a different origin.
An attacker who controls the target of a redirect from a trusted URL can have their response cached under that trusted URL. A later caller requesting the trusted URL receives the attacker's body from the shared cache without either origin being contacted, allowing persistent cache poisoning. The same key confusion also discloses private data: when an authenticated request returns a private, no-store redirect to a user-specific resource, the final response is stored under the original URL and can be served to a later unauthenticated caller.
The cache interceptor was introduced in undici 7.0.0, and all 7.x and 8.x releases before the patched versions are affected. Applications are affected only when an originless Agent, a shared MemoryCacheStore or SqliteCacheStore, and the composition compose(redirect(), cache()) are all used. Origin-bound Client and Pool dispatchers, and the reverse composition compose(cache(), redirect()), are not affected.
Patches
Upgrade to 7.30.1 or 8.12.2. Before storing a response, undici now verifies that the origin that produced it still matches the cache key, and preserves each redirect hop's cache-control policy, so cross-origin redirect responses and responses behind a no-store or private hop are no longer cached under the original key.
Workarounds
Compose the interceptors as compose(cache(), redirect()), use per-origin dispatchers and cache stores, or disable shared caching on redirect-capable requests.
Impact
undici's Agent passes its constructor options through a JSON-based deep clone (JSON.parse(JSON.stringify(...))) before forwarding them to each per-origin Pool. JSON cannot represent functions, so a caller-supplied tls option containing a checkServerIdentity callback is silently dropped before it reaches the TLS layer. As a result, a TLS peer whose certificate a custom checkServerIdentity was written to reject, but which passes Node's default hostname and chain checks, is silently accepted when the request is made through Agent. Because Agent is the default dispatcher behind request, fetch, and setGlobalDispatcher, this is the path most applications use. EnvHttpProxyAgent is also affected on its direct and NOPROXY routes, which delegate to an internal Agent.
Only applications that pass a function-valued tls option (such as a custom checkServerIdentity for certificate or public-key pinning) are affected. Passing the same options through connect is not affected. This is the Agent counterpart of the BalancedPool certificate validation bypass fixed in CVE-2026-84961.
Patches
Upgrade to undici 6.29.1, 7.30.1, or 8.12.2. Agent now preserves the tls option outside the JSON clone, so custom TLS verification callbacks are forwarded to each origin unchanged.
Workarounds
Pass the TLS options through connect instead of tls. For proxied EnvHttpProxyAgent destinations, use requestTls / proxyTls.
Impact
undici's fetch() verifies Subresource Integrity (SRI) metadata by looking up the algorithm token in a lowercase-only set, but the SRI specification defines a valid token by its ASCII-lowercase form. A correct but non-lowercase token such as SHA256-... or Sha256-... is therefore treated as unknown and skipped. When no recognized algorithm remains, undici treats the integrity list as empty and accepts the response, so a server that returns a body different from the pinned digest passes the check.
An application that pins a response with a valid uppercase or mixed-case SRI token receives attacker-controlled bytes with no integrity error. The attacker needs only to control the response body, not the application's integrity metadata. The issue affects response integrity only. The regression was introduced in undici 7.15.0; releases 7.14.0 and earlier lowercase the token and are not affected.
Patches
Upgrade to 7.30.1 or 8.12.2. undici now normalizes the algorithm token to ASCII lowercase before validating it and before selecting the strongest algorithm, so case variants of SHA-256, SHA-384, and SHA-512 are verified correctly.
Workarounds
Use lowercase algorithm tokens (sha256, sha384, sha512) in integrity metadata.
Impact
undici's WebSocket client (including Node.js's bundled globalThis.WebSocket) can be driven to exhaust process memory by a malicious or compromised WebSocket server. For every PING frame received, the receiver automatically writes a PONG response to the socket and ignores the false return value from socket.write(), which is a backpressure signal, so a server that streams small PING frames while never reading the client's PONGs makes the outbound write queue and heap grow without bound until the Node.js process runs out of memory and terminates. The attack is remote and unauthenticated, needs only a normal WebSocket connection, and is asymmetric: small inbound PINGs produce a much larger retained outbound queue. Availability is the only impact. undici 5.x, 6.x, 7.x, and 8.x are affected; the WebSocket client was introduced in 5.15.0.
Patches
Upgrade to 6.29.1, 7.30.1, or 8.12.2, which pause WebSocket frame parsing when the automatic PONG response hits socket backpressure and resume on drain, bounding the outbound queue.
Workarounds
None.
Impact
Undici's interceptors.retry() can resume a request after a partial response and append the resumed bytes to an already partially delivered body, while the application still receives the original response's status and headers. When that response carried a Content-Length, the application can receive a longer body. Applications that forward Undici's status, headers, and body downstream without recalculating framing, for example proxy or gateway applications, may emit a response whose body exceeds the forwarded Content-Length, and the excess bytes can be read as the start of a subsequent HTTP response (downstream response splitting or desynchronization).
For example, a 404 Not Found with Content-Length: 2 that sends one byte then closes can be resumed with an open-ended Range request, and the resumed 206 Partial Content bytes are appended, so the application receives more than two body bytes while still seeing Content-Length: 2. The bug requires interceptors.retry() enabled, an attacker-controlled or faulty upstream, and a downstream forwarder that does not recalculate Content-Length.
Patches
Patched in undici v6.28.1, v7.29.1, and v8.10.2. Upgrade to one of these or later.
Workarounds
- Disable interceptors.retry() for untrusted upstreams, or set maxRetries: 0. - Remove or recalculate Content-Length before forwarding a response body assembled by Undici.
Impact
The undici WebSocket client throws an uncaught TypeError during the opening handshake when a server's 101 response includes a Sec-WebSocket-Protocol header that the client never requested. The throw occurs in a queueMicrotask callback with no surrounding try/catch, so it propagates as an uncaught exception and terminates the Node.js process. This is a remote, unauthenticated denial of service against any application that opens a WebSocket to an attacker controlled or compromised server, or over a plaintext ws:// connection subject to a machine-in-the-middle. It affects the default new WebSocket(url) usage, where no subprotocol is requested. Per RFC 6455 section 4.1, an unrequested subprotocol must fail the connection, not crash it.
All releases starting at undici 6.7.0 are affected.
Patches
Upgrade to undici 6.28.1, 7.29.1, or 8.10.2.
Workarounds
No workaround is available. The fix must be applied through an upgrade.
Impact
The interceptors.decompress() interceptor decompresses HTTP response bodies according to the untrusted Content-Encoding header. The number of decompression layers is capped at 5, but the total decompressed output size is not bounded and there is no option to limit it. A malicious or faulty upstream can return a small compressed payload (a compression bomb) that expands to hundreds of megabytes or gigabytes in client memory, exhausting memory and causing the Node.js process to crash or become unresponsive. Any application using the decompress interceptor to read responses from untrusted or compromised upstreams is affected.
Patches
Upgrade to 7.29.1 or 8.10.2. The interceptor now accepts a maxSize option (default 64 MiB) and rejects responses whose decompressed output exceeds it with a ResponseExceededMaxSizeError.
Workarounds
Once upgraded, set a conservative maxSize on the interceptor. Before upgrading, avoid using interceptors.decompress() with untrusted upstreams, or apply a custom interceptor that enforces a decompressed output size limit.
Impact
undici's WebSocketStream crashes the client process when a WebSocket connection is closed abruptly without a close handshake. On such an unclean close, the internal socket-close handler calls abort() on the writable stream even when the application holds a writer lock. Per the WHATWG Streams standard, aborting a locked stream returns a promise that rejects with a TypeError, and the handler discards that promise. The unobserved rejection surfaces as an unhandledRejection and, under Node.js's default behavior, terminates the process.
A malicious or compromised WebSocket server can crash a client with a single connection teardown (a TCP reset, a proxy teardown, or a protocol-violating frame). Affected applications are those using the WebSocketStream API and writing through a writer, which is the standard way to write.
All releases from undici 7.0.0 are affected. WebSocketStream was introduced in 7.0.0.
Patches
Upgrade to undici v7.29.1 or v8.10.2.
Workarounds
No workaround is available.
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.
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.
Updates are now available for the 26.x, 24.x, 22.x Node.js release lines for the following issues.
This security release includes the following dependency updates to address public vulnerabilities:
undici (8.9.0, 7.29.0, 6.28.0) on 26.x, 24.x, 22.x
llhttp (9.4.3) on 26.x, 24.x, 22.x
Updates are now available for the 26.x, 24.x, 22.x Node.js release lines for the following issues.
This security release includes the following dependency updates to address public vulnerabilities:
llhttp (9.4.2) on all release lines
nghttp2 (1.69.0) on all release lines
openssl (3.5.7) on all release lines
undici (8.5.0) on 26.3.1
undici (7.28.0) on 24.17.0
undici (6.27.0) on 22.23.0
Impact: When using Socks5ProxyAgent, undici reuses a single connection pool across different origins without verifying that the pool's origin matches the requested origin. All requests are dispatched through the pool connected to the first origin, regardless of the intended destination.
This causes cross-origin request routing: credentials and request data intended for origin B are sent to origin A, responses from the wrong origin are trusted, and HTTPS requests may be silently downgraded to HTTP.
Impacted users are applications that use Socks5ProxyAgent (directly or via setGlobalDispatcher) and make requests to more than one origin.
This was introduced in undici 7.23.0 via PR #4385 and affects all versions through 8.1.0.
Patches: Upgrade to undici v7.26.0 or v8.2.0.
Workarounds: Use a separate Socks5ProxyAgent instance per origin, or avoid using Socks5ProxyAgent with multiple origins.
Impact: Undici's HTTP/1.1 client is vulnerable to response queue poisoning on reused keep-alive sockets. An attacker-controlled upstream server can inject an unsolicited HTTP/1.1 response onto an idle socket after a request completes. When the client dispatches the next request on that socket, it associates the injected response with the new request, causing responses to be delivered to the wrong requests.
This requires an attacker-controlled or compromised upstream HTTP/1.1 server and keep-alive connection reuse.
Patches: Upgrade to undici v6.26.0, v7.28.0 or v8.5.0.
Workarounds: Disable keep-alive connection reuse by setting keepAliveTimeout: 0 on the Client or Pool.
Impact: Undici's cache interceptor incorrectly classifies some responses as cacheable when the upstream Cache-Control header uses whitespace-padded qualified private or no-cache field names such as private=" authorization" or no-cache="\tauthorization". The parser preserves the surrounding whitespace, so later comparisons against the literal authorization field name fail 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.
Affected applications are those that explicitly enable the cache interceptor (interceptors.cache()) in shared mode, forward Authorization headers upstream, and receive cacheable responses with non-canonical qualified private or no-cache directives.
Patches: Upgrade to undici v7.28.0 or v8.5.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
When undici parses a Set-Cookie header, it accepts any SameSite attribute value that contains Strict, Lax, or None as a substring, rather than the case-insensitive exact match specified by RFC 6265. Non-spec values are silently mapped to one of the three standard tokens:
- SameSite=NoneOfYourBusiness is parsed as None, the most permissive setting. - SameSite=StrictLax is parsed as Lax, a downgrade from Strict.
Affected applications are those that consume Set-Cookie headers from server responses (for example via undici's fetch or proxy code paths) and then forward or rely on the parsed sameSite attribute. A malicious or non-compliant server can coerce the consumer's view of a cookie's SameSite policy to a weaker value, silently degrading the SameSite enforcement the cookie is supposed to provide.
This was introduced in undici 5.15.0 when the cookies feature was added.
Patches
Upgrade to undici v6.27.0, v7.28.0 or v8.5.0.
Workarounds
After parsing a Set-Cookie header, validate that the resulting sameSite attribute is one of 'Strict', 'Lax', or 'None' (exact, case-insensitive) before forwarding or relying on it.
Impact
Undici's HTTP/1.1 client is vulnerable to response queue poisoning on reused keep-alive sockets. An attacker-controlled upstream server can inject an unsolicited HTTP/1.1 response onto an idle socket after a request completes. When the client dispatches the next request on that socket, it associates the injected response with the new request, causing responses to be delivered to the wrong requests.
This requires an attacker-controlled or compromised upstream HTTP/1.1 server and keep-alive connection reuse.
Patches
Upgrade to undici v6.27.0, v7.28.0 or v8.5.0.
Workarounds
Disable keep-alive connection reuse by setting keepAliveTimeout: 0 on the Client or Pool.
Impact
Undici's cache interceptor incorrectly classifies some responses as cacheable when the upstream Cache-Control header uses whitespace-padded qualified private or no-cache field names such as private=" authorization" or no-cache="\tauthorization". The parser preserves the surrounding whitespace, so later comparisons against the literal authorization field name fail 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.
Affected applications are those that explicitly enable the cache interceptor (interceptors.cache()) in shared mode, forward Authorization headers upstream, and receive cacheable responses with non-canonical qualified private or no-cache directives.
Patches
Upgrade to undici v7.28.0 or v8.5.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: The undici WebSocket client enforces maxPayloadSize on the cumulative byte count of fragments in a message but does not enforce a limit on the number of fragments. A malicious WebSocket server can stream many small or empty continuation frames that each pass per-frame and cumulative-size validation, collectively causing unbounded memory growth in the client process. The result is memory exhaustion and a denial of service.
Affected applications are those using the undici WebSocket client (new WebSocket(...)) or the WebSocketStream API that can be induced to connect to an attacker-controlled or compromised WebSocket endpoint.
All releases starting at undici 6.17.0 are affected.
Patches: Upgrade to undici >= 6.26.0, >= 7.28.0, or >= 8.5.0. Workarounds: No workaround is available. The fix must be applied through an upgrade.
Impact
undici's cookie parser in parseSetCookie percent-decodes cookie values via qsUnescape, turning encoded sequences like %0D%0A, %00, %3B, and %3D into their literal byte equivalents. RFC 6265 §5.4 does not specify any decoding and browsers do not decode either.
Applications that parse a Set-Cookie header and then forward the parsed value into a response header (proxies, middleware, SSR frameworks) become vulnerable to HTTP response header injection: an attacker-controlled upstream can inject arbitrary Set-Cookie, Location, or Cache-Control headers into the application's downstream response, enabling session fixation, open redirect, or cache poisoning.
Affected applications are those that use undici's cookie parsing (parseSetCookie, parseCookie, getSetCookies) and forward the parsed cookie value into a response header.
This was introduced in undici 7.0.0 via #3789.
Patches
Upgrade to undici v6.27.0, v7.28.0 or v8.5.0.
Workarounds
If upgrade is not immediately possible, do not forward values returned by parseSetCookie/parseCookie/getSetCookies directly into response headers; sanitize the value first to strip or reject CR, LF, NUL, ;, and = bytes.
Impact
undici's ProxyAgent silently drops the requestTls option when configured with a SOCKS5 proxy URI (socks5:// or socks://). The target HTTPS connection through the SOCKS5 tunnel falls back to Node's default trust store, ignoring user-configured ca, cert, key, rejectUnauthorized, and servername settings.
Applications that pin to an internal or corporate CA via requestTls.ca will, when their proxy URI is SOCKS5, get the default Mozilla CA bundle as the trust anchor instead. Any cert signed by any publicly-trusted CA for the target hostname is accepted, breaking the intended pin and enabling MITM read and tamper of the HTTPS exchange.
Affected applications are those that use undici's ProxyAgent (or Socks5ProxyAgent directly) with SOCKS5 AND rely on requestTls for TLS scope restriction. The bug was introduced in undici 7.23.0 when SOCKS5 support was added.
Patches
Upgrade to undici v7.28.0 or v8.5.0.
Workarounds
No workaround is available within the SOCKS5 path. If a SOCKS5 proxy with TLS scope restriction is required and an upgrade is not yet possible, route the traffic through an HTTP-proxy ProxyAgent instead, where requestTls is honored correctly.
Impact
When using Socks5ProxyAgent, undici reuses a single connection pool across different origins without verifying that the pool's origin matches the requested origin. All requests are dispatched through the pool connected to the first origin, regardless of the intended destination.
This causes cross-origin request routing: credentials and request data intended for origin B are sent to origin A, responses from the wrong origin are trusted, and HTTPS requests may be silently downgraded to HTTP.
Impacted users are applications that use Socks5ProxyAgent (directly or via setGlobalDispatcher) and make requests to more than one origin.
This was introduced in undici 7.23.0 via #4385 and affects all versions through 8.1.0.
Patches
Upgrade to undici v7.28.0 or v8.2.0
Workarounds
Use a separate Socks5ProxyAgent instance per origin, or avoid using Socks5ProxyAgent with multiple origins.
Impact
The undici WebSocket client enforces maxPayloadSize per-frame but does not enforce the cumulative size of fragmented uncompressed messages. A malicious WebSocket server can stream many small fragments that each pass per-frame validation but collectively exceed the configured limit, causing unbounded memory growth in the client process. The result is memory exhaustion and a denial of service.
Affected applications are those using the undici WebSocket client (new WebSocket(...)) that can be induced to connect to an attacker-controlled or compromised WebSocket endpoint.
This is a regression specific to undici 8.1.0. The 6.25.0 line shipped the equivalent cumulative check from the start and is unaffected. The 7.x line never had the maxPayloadSize feature and is also unaffected.
Patches
Upgrade to undici >= 8.5.0.
Workarounds
No workaround is available. The fix must be applied through an upgrade.
Impact
The undici WebSocket client enforces maxPayloadSize on the cumulative byte count of fragments in a message but does not enforce a limit on the number of fragments. A malicious WebSocket server can stream many small or empty continuation frames that each pass per-frame and cumulative-size validation, collectively causing unbounded memory growth in the client process. The result is memory exhaustion and a denial of service.
Affected applications are those using the undici WebSocket client (new WebSocket(...)) or the WebSocketStream API that can be induced to connect to an attacker-controlled or compromised WebSocket endpoint.
All releases starting at undici 6.17.0 are affected.
Patches
Upgrade to undici v6.27.0, v7.28.0 or v8.5.0.
Workarounds
No workaround is available. The fix must be applied through an upgrade.