Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
55 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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…
Recommended action: Upgrade to 8.5.0, 7.28.0 or 6.27.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 8.5.0, 7.28.0 or 6.27.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 8.5.0, 7.28.0 or 6.27.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 8.2.0 or 7.28.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 8.5.0, 7.28.0 or 6.27.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 8.5.0 or 7.28.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 8.5.0 or 7.28.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 8.5.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The undici WebSocket client is vulnerable to a denial-of-service attack via unbounded memory consumption during permessage-deflate decompression. When a WebSocket connection negotiates the permessage-deflate extension, the client decompresses incoming compressed frames without enforcing any limit on the decompressed data size. 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. The vulnerability exists in the PerMessageDeflate.decompress() method, which accumulates all decompressed chunks in memory and concatenates them into a single Buffer without checking whether the total size exceeds a safe threshold. Impact - Remote denial of service against any Node.js application using undici's WebSocket client - A single compressed WebSocket frame of ~6 MB can decompress to ~1 GB or more - Memory exhaustion…
Recommended action: Upgrade to 7.24.0 or 6.24.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The undici WebSocket client is vulnerable to a denial-of-service attack due to improper validation of the servermaxwindowbits parameter in the permessage-deflate extension. When a WebSocket client connects to a server, it automatically advertises support for permessage-deflate compression. A malicious server can respond with an out-of-range servermaxwindowbits value (outside zlib's valid range of 8-15). When the server subsequently sends a compressed frame, the client attempts to create a zlib InflateRaw instance with the invalid windowBits value, causing a synchronous RangeError exception that is not caught, resulting in immediate process termination. The vulnerability exists because: 1. The isValidClientWindowBits() function only validates that the value contains ASCII digits, not that it falls within the valid range 8-15 2. The createInflateRaw() call is not wrapped in a try-catch block 3. The resulting exception propagates up through the call stack and crashes the Node.js…
Recommended action: Upgrade to 7.24.0 or 6.24.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact When an application passes user-controlled input to the upgrade option of client.request(), an attacker can inject CRLF sequences (\r\n) to: 1. Inject arbitrary HTTP headers 2. Terminate the HTTP request prematurely and smuggle raw data to non-HTTP services (Redis, Memcached, Elasticsearch) The vulnerability exists because undici writes the upgrade value directly to the socket without validating for invalid header characters: Patches Patched in the undici version v7.24.0 and v6.24.0. Users should upgrade to this version or later. Workarounds Sanitize the upgrade option string before passing to undici:
Recommended action: Upgrade to 7.24.0 or 6.24.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact This is an uncontrolled resource consumption vulnerability (CWE-400) that can lead to Denial of Service (DoS). In vulnerable Undici versions, when interceptors.deduplicate() is enabled, response data for deduplicated requests could be accumulated in memory for downstream handlers. An attacker-controlled or untrusted upstream endpoint can exploit this with large/chunked responses and concurrent identical requests, causing high memory usage and potential OOM process termination. Impacted users are applications that use Undici’s deduplication interceptor against endpoints that may produce large or long-lived response bodies. Patches The issue has been patched by changing deduplication behavior to stream response chunks to downstream handlers as they arrive (instead of full-body accumulation), and by preventing late deduplication when body streaming has already started. Users should upgrade to the first official Undici (and Node.js, where applicable) releases that include this…
Recommended action: Upgrade to 7.24.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A server can reply with a WebSocket frame using the 64-bit length form and an extremely large length. undici's ByteParser overflows internal math, ends up in an invalid state, and throws a fatal TypeError that terminates the process. Patches Patched in the undici version v7.24.0 and v6.24.0. Users should upgrade to this version or later. Workarounds There are no workarounds.
Recommended action: Upgrade to 7.24.0 or 6.24.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Undici allows duplicate HTTP Content-Length headers when they are provided in an array with case-variant names (e.g., Content-Length and content-length). This produces malformed HTTP/1.1 requests with multiple conflicting Content-Length values on the wire. Who is impacted: - Applications using undici.request(), undici.Client, or similar low-level APIs with headers passed as flat arrays - Applications that accept user-controlled header names without case-normalization Potential consequences: - Denial of Service: Strict HTTP parsers (proxies, servers) will reject requests with duplicate Content-Length headers (400 Bad Request) - HTTP Request Smuggling: In deployments where an intermediary and backend interpret duplicate headers inconsistently (e.g., one uses the first value, the other uses the last), this can enable request smuggling attacks leading to ACL bypass, cache poisoning, or credential hijacking Patches Patched in the undici version v7.24.0 and v6.24.0. Users should…
Recommended action: Upgrade to 7.24.0 or 6.24.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The fetch() API supports chained HTTP encoding algorithms for response content according to RFC 9110 (e.g., Content-Encoding: gzip, br). This is also supported by the undici decompress interceptor. However, the number of links in the decompression chain is unbounded and the default maxHeaderSize allows a malicious server to insert thousands compression steps leading to high CPU usage and excessive memory allocation. Patches Upgrade to 7.18.2 or 6.23.0. Workarounds It is possible to apply an undici interceptor and filter long Content-Encoding sequences manually. References https://hackerone.com/reports/3456148 https://github.com/advisories/GHSA-gm62-xv2j-4w53 https://curl.se/docs/CVE-2022-32206.html
Recommended action: Upgrade to 7.18.2 or 6.23.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Applications that use undici to implement a webhook-like system are vulnerable. If the attacker set up a server with an invalid certificate, and they can force the application to call the webhook repeatedly, then they can cause a memory leak. Patches This has been patched in https://github.com/nodejs/undici/pull/4088. Workarounds If a webhook fails, avoid keep calling it repeatedly. References Reported as: https://github.com/nodejs/undici/issues/3895
Recommended action: Upgrade to 7.5.0, 6.21.2 or 5.29.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Undici fetch() uses Math.random() to choose the boundary for a multipart/form-data request. It is known that the output of Math.random() can be predicted if several of its generated values are known. If there is a mechanism in an app that sends multipart requests to an attacker-controlled website, they can use this to leak the necessary values. Therefore, An attacker can tamper with the requests going to the backend APIs if certain conditions are met. Patches This is fixed in 5.28.5; 6.21.1; 7.2.3. Workarounds Do not issue multipart requests to attacker controlled servers. References https://hackerone.com/reports/2913312 https://blog.securityevaluators.com/hacking-the-javascript-lottery-80cc437e3b7f
Recommended action: Upgrade to 7.2.3, 6.21.1 or 5.28.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Depending on network and process conditions of a fetch() request, response.arrayBuffer() might include portion of memory from the Node.js process. Patches This has been patched in v6.19.2. Workarounds There are no known workaround. References https://github.com/nodejs/undici/issues/3337 https://github.com/nodejs/undici/issues/3328 https://github.com/nodejs/undici/pull/3338 https://github.com/nodejs/undici/commit/f979ec3204ca489abf30e7d20e9fee9ea7711d36
Recommended action: Upgrade to 6.19.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact If an attacker can alter the integrity option passed to fetch(), they can let fetch() accept requests as valid even if they have been tampered. Patches Fixed in https://github.com/nodejs/undici/commit/d542b8cd39ec1ba303f038ea26098c3f355974f3. Fixes has been released in v5.28.4 and v6.11.1. Workarounds Ensure that integrity cannot be tampered with. References https://hackerone.com/reports/2377760
Recommended action: Upgrade to 6.11.1 or 5.28.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Undici cleared Authorization and Proxy-Authorization headers for fetch(), but did not clear them for undici.request(). Patches This has been patched in https://github.com/nodejs/undici/commit/6805746680d27a5369d7fb67bc05f95a28247d75. Fixes has been released in v5.28.4 and v6.11.1. Workarounds use fetch() or disable maxRedirections. References Linzi Shang reported this. https://hackerone.com/reports/2408074 https://github.com/nodejs/undici/security/advisories/GHSA-3787-6prv-h9w3
Recommended action: Upgrade to 6.11.1 or 5.28.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Undici already cleared Authorization headers on cross-origin redirects, but did not clear Proxy-Authorization headers. Patches This is patched in v5.28.3 and v6.6.1 Workarounds There are no known workarounds. References - https://fetch.spec.whatwg.org/#authentication-entries - https://github.com/nodejs/undici/security/advisories/GHSA-wqq4-5wpv-mx2g
Recommended action: Upgrade to 6.6.1 or 5.28.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Calling fetch(url) and not consuming the incoming body ((or consuming it very slowing) will lead to a memory leak. Patches Patched in v6.6.1 Workarounds Make sure to always consume the incoming body.
Recommended action: Upgrade to 6.6.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Undici clears Authorization headers on cross-origin redirects, but does not clear Cookie headers. By design, cookie headers are forbidden request headers, disallowing them to be set in RequestInit.headers in browser environments. Since Undici handles headers more liberally than the specification, there was a disconnect from the assumptions the spec made, and Undici's implementation of fetch. As such this may lead to accidental leakage of cookie to a 3rd-party site or a malicious attacker who can control the redirection target (ie. an open redirector) to leak the cookie to the 3rd party site. Patches This was patched in e041de359221ebeae04c469e8aff4145764e6d76, which is included in version 5.26.2.
Recommended action: Upgrade to 5.26.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact undici library does not protect host HTTP header from CRLF injection vulnerabilities. Patches This issue was patched in Undici v5.19.1. Workarounds Sanitize the headers.host string before passing to undici. References Reported at https://hackerone.com/reports/1820955. Credits Thank you to Zhipeng Zhang (@timon8) for reporting this vulnerability.
Recommended action: Upgrade to 5.19.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The Headers.set() and Headers.append() methods are vulnerable to Regular Expression Denial of Service (ReDoS) attacks when untrusted values are passed into the functions. This is due to the inefficient regular expression used to normalize the values in the headerValueNormalize() utility function. Patches This vulnerability was patched in v5.19.1. Workarounds There is no workaround. Please update to an unaffected version. References https://hackerone.com/bugs?reportid=1784449 Credits Carter Snook reported this vulnerability.
Recommended action: Upgrade to 5.19.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.