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.
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. 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 server_max_window_bits 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 …
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 …
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 …
When an application passes user-controlled input to the upgrade option of client.request(), an attacker can inject CRLF sequences (\r\n) to: Inject arbitrary HTTP headers 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: // lib/dispatcher/client-h1.js:1121 if (upgrade) { header += connection: upgrade\r\nupgrade: ${upgrade}\r\n }
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 …
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.
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.
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 …
Depending on network and process conditions of a fetch() request, response.arrayBuffer() might include portion of memory from the Node.js process.
Undici cleared Authorization and Proxy-Authorization headers for fetch(), but did not clear them for undici.request().
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.
Undici is an HTTP/1.1 client, written from scratch for Node.js. In affected versions calling fetch(url) and not consuming the incoming body ((or consuming it very slowing) will lead to a memory leak. This issue has been addressed in version 6.6.1. Users are advised to upgrade. Users unable to upgrade should make sure to always consume the incoming body.
Undici is an HTTP/1.1 client, written from scratch for Node.js. Undici already cleared Authorization headers on cross-origin redirects, but does not clear Proxy-Authentication headers. This issue has been patched in versions 5.28.3 and 6.6.1. Users are advised to upgrade. There are no known workarounds for this vulnerability.
Undici is an HTTP/1.1 client written from scratch for Node.js. Prior to version 5.26.2, Undici already cleared 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 spec, there was a disconnect from the assumptions the spec made, and undici's implementation of fetch. …
Undici is an HTTP/1.1 client for Node.js. Prior to version 5.19.1, the Headers.set() and Headers.append() methods is 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. This vulnerability was patched in v5.19.1. No known workarounds are available.
Undici is an HTTP/1.1 client for Node.js. Starting with version 2.0.0 and prior to version 5.19.1, the undici library does not protect host HTTP header from CRLF injection vulnerabilities. This issue is patched in Undici v5.19.1. As a workaround, sanitize the headers.host string before passing to undici.
undici is an HTTP/1.1 client, written from scratch for Node.js.=< undici@5.8.0 users is vulnerable to CRLF Injection on headers when using unsanitized input as request headers, more specifically, inside the content-type header. Example: import { request } from 'undici' const unsanitizedContentTypeInput = 'application/json\r\n\r\nGET /foo2 HTTP/1.1' await request('http://localhost:3000, { method: 'GET', headers: { 'content-type': unsanitizedContentTypeInput }, }) The above snippet will perform two requests in a single request API call: 1) …
undici is an HTTP/1.1 client, written from scratch for Node.js.undici is vulnerable to SSRF (Server-side Request Forgery) when an application takes in user input into the path/pathname option of undici.request. If a user specifies a URL such as http://127.0.0.1 or //127.0.0.1 js const undici = require("undici") undici.request({origin: "http://example.com", pathname: "//127.0.0.1"}) Instead of processing the request as http://example.org//127.0.0.1 (or http://example.org/http://127.0.0.1 when http://127.0.0.1 is used), it actually processes the request as http://127.0.0.1/ …
Authorization headers are cleared on cross-origin redirect. However, cookie headers which are sensitive headers and are official headers found in the spec, remain uncleared. There are active users using cookie headers in undici. 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. This was …
undici is an HTTP/1.1 client, written from scratch for Node.js. It is possible to inject CRLF sequences into request headers in undici in versions less than 5.7.1. A fix was released in version 5.8.0. Sanitizing all HTTP headers from untrusted sources to eliminate \r\n is a workaround for this issue.
Undici.ProxyAgent never verifies the remote server's certificate, and always exposes all request & response data to the proxy. This unexpectedly means that proxies can MitM all HTTPS traffic, and if the proxy's URL is HTTP then it also means that nominally HTTPS requests are actually sent via plain-text HTTP between Undici and the proxy server.
This advisory duplicates another.