All the vulnerabilities related to the version 5.0.0 of the package
ProxyAgent vulnerable to MITM
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 affects all use of HTTPS via HTTP proxy using Undici.ProxyAgent with Undici or Node's global fetch. In this case, it removes all HTTPS security from all requests sent using Undici's ProxyAgent, allowing trivial MitM attacks by anybody on the network path between the client and the target server (local network users, your ISP, the proxy, the target server's ISP, etc).
This less seriously affects HTTPS via HTTPS proxies. When you send HTTPS via a proxy to a remote server, the proxy can freely view or modify all HTTPS traffic unexpectedly (but only the proxy).
This issue was patched in Undici v5.5.1.
At the time of writing, the only workaround is to not use ProxyAgent as a dispatcher for TLS Connections.
undici before v5.8.0 vulnerable to CRLF injection in request headers
It is possible to inject CRLF sequences into request headers in Undici.
const undici = require('undici')
const response = undici.request("http://127.0.0.1:1000", {
headers: {'a': "\r\nb"}
})
The same applies to path and method
Update to v5.8.0
Sanitize all HTTP headers from untrusted sources to eliminate \r\n.
https://hackerone.com/reports/409943 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-12116
If you have any questions or comments about this advisory:
undici before v5.8.0 vulnerable to uncleared cookies on cross-host / cross-origin redirect
Authorization headers are already cleared on cross-origin redirect in https://github.com/nodejs/undici/blob/main/lib/handler/redirect.js#L189, based on https://github.com/nodejs/undici/issues/872.
However, cookie headers which are sensitive headers and are official headers found in the spec, remain uncleared. There also has been active discussion of implementing a cookie store https://github.com/nodejs/undici/pull/1441, which suggests that there are active users using cookie headers in undici. 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.
This was patched in v5.8.0.
By default, this vulnerability is not exploitable.
Do not enable redirections, i.e. maxRedirections: 0 (the default).
https://hackerone.com/reports/1635514 https://curl.se/docs/CVE-2018-1000007.html https://curl.se/docs/CVE-2022-27776.html
If you have any questions or comments about this advisory:
undici.request vulnerable to SSRF using absolute URL on pathname
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
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/ and sends it to http://127.0.0.1.
If a developer passes in user input into path parameter of undici.request, it can result in an SSRF as they will assume that the hostname cannot change, when in actual fact it can change because the specified path parameter is combined with the base URL.
This issue was fixed in undici@5.8.1.
The best workaround is to validate user input before passing it to the undici.request call.
If you have any questions or comments about this advisory:
Nodejs ‘undici’ vulnerable to CRLF Injection via Content-Type
=< undici@5.8.0 users are 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:
http://localhost:3000/http://localhost:3000/foo2This issue was patched in Undici v5.8.1
Sanitize input when sending content-type headers using user input.
If you have any questions or comments about this advisory:
CRLF Injection in Nodejs ‘undici’ via host
undici library does not protect host HTTP header from CRLF injection vulnerabilities.
This issue was patched in Undici v5.19.1.
Sanitize the headers.host string before passing to undici.
Reported at https://hackerone.com/reports/1820955.
Thank you to Zhipeng Zhang (@timon8) for reporting this vulnerability.
Regular Expression Denial of Service in Headers
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.
This vulnerability was patched in v5.19.1.
There is no workaround. Please update to an unaffected version.
Carter Snook reported this vulnerability.
Undici's cookie header not cleared on cross-origin redirect in fetch
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.
This was patched in e041de359221ebeae04c469e8aff4145764e6d76, which is included in version 5.26.2.
Undici proxy-authorization header not cleared on cross-origin redirect in fetch
Undici already cleared Authorization headers on cross-origin redirects, but did not clear Proxy-Authorization headers.
This is patched in v5.28.3 and v6.6.1
There are no known workarounds.
Undici's fetch with integrity option is too lax when algorithm is specified but hash value is in incorrect
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.
Fixed in https://github.com/nodejs/undici/commit/d542b8cd39ec1ba303f038ea26098c3f355974f3. Fixes has been released in v5.28.4 and v6.11.1.
Ensure that integrity cannot be tampered with.
https://hackerone.com/reports/2377760
Undici's Proxy-Authorization header not cleared on cross-origin redirect for dispatch, request, stream, pipeline
Undici cleared Authorization and Proxy-Authorization headers for fetch(), but did not clear them for undici.request().
This has been patched in https://github.com/nodejs/undici/commit/6805746680d27a5369d7fb67bc05f95a28247d75. Fixes has been released in v5.28.4 and v6.11.1.
use fetch() or disable maxRedirections.
Linzi Shang reported this.
Use of Insufficiently Random Values in undici
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.
This is fixed in 5.28.5; 6.21.1; 7.2.3.
Do not issue multipart requests to attacker controlled servers.
undici Denial of Service attack via bad certificate data
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.
This has been patched in https://github.com/nodejs/undici/pull/4088.
If a webhook fails, avoid keep calling it repeatedly.
Reported as: https://github.com/nodejs/undici/issues/3895