Advisories for Npm/Undici package

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.

Undici.ProxyAgent never verifies the remote server's certificate, and always exposes all request & response data to the proxy.