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 =< 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: The above snippet will perform two requests in a single request API call: 1) http://localhost:3000/ 2) http://localhost:3000/foo2 Patches This issue was patched in Undici v5.8.1 Workarounds Sanitize input when sending content-type headers using user input. For more information If you have any questions or comments about this advisory: - Open an issue in undici repository - To make a report, follow the SECURITY document
Recommended action: Upgrade to 5.8.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 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 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. Patches This issue was fixed in undici@5.8.1. Workarounds The best workaround is to validate user input before passing it to the undici.request call. For more information If you have any questions or comments about this advisory: - Open an issue in undici repository - To make a report, follow…
Recommended action: Upgrade to 5.8.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact 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. Patches This was patched in v5.8.0. Workarounds By default, this vulnerability is not exploitable. Do not enable redirections, i.e. maxRedirections: 0 (the default). References https://hackerone.com/reports/1635514 https://curl.se/docs/CVE-2018-1000007.html…
Recommended action: Upgrade to 5.8.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact It is possible to inject CRLF sequences into request headers in Undici. The same applies to path and method Patches Update to v5.8.0 Workarounds Sanitize all HTTP headers from untrusted sources to eliminate \r\n. References https://hackerone.com/reports/409943 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-12116 For more information If you have any questions or comments about this advisory: Open an issue in undici repository To make a report, follow the SECURITY document
Recommended action: Upgrade to 5.8.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Impact 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). Patches This issue was patched in Undici v5.5.1. Workarounds At…
Recommended action: Upgrade to 5.5.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.