Search for packages
| purl | pkg:npm/undici@3.3.2 |
| Vulnerability | Summary | Fixed by |
|---|---|---|
|
VCID-1294-r4v2-3ud7
Aliases: CVE-2025-47279 GHSA-cxrh-j4jr-qwg3 |
undici Denial of Service attack via bad certificate data ### 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 |
Affected by 5 other vulnerabilities. Affected by 6 other vulnerabilities. Affected by 6 other vulnerabilities. |
|
VCID-dtvs-pgam-qkbp
Aliases: CVE-2023-23936 GHSA-5r9g-qh6m-jxff |
CRLF Injection in Nodejs ‘undici’ via host 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. |
Affected by 11 other vulnerabilities. |
|
VCID-g4wu-n75v-p7ad
Aliases: CVE-2022-35949 GHSA-8qr4-xgw6-wmr3 |
`undici.request` vulnerable to SSRF using absolute URL on `pathname` ### 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` ```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/` 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](https://github.com/nodejs/undici/issues) - To make a report, follow the [SECURITY](https://github.com/nodejs/node/blob/HEAD/SECURITY.md) document |
Affected by 13 other vulnerabilities. |
|
VCID-hgd1-7u6j-p7dh
Aliases: CVE-2026-2229 GHSA-v9p9-hfj2-hcw8 |
Undici has Unhandled Exception in WebSocket Client Due to Invalid server_max_window_bits Validation ### Impact 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 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 process ### Patches _Has the problem been patched? What versions should users upgrade to?_ ### Workarounds _Is there a way for users to fix or remediate the vulnerability without upgrading?_ |
Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-huz5-2qv3-g3an
Aliases: CVE-2023-45143 GHSA-wqq4-5wpv-mx2g |
Exposure of Sensitive Information to an Unauthorized Actor 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. As such this may lead to accidental leakage of cookie to a third-party site or a malicious attacker who can control the redirection target (ie. an open redirector) to leak the cookie to the third party site. This was patched in version 5.26.2. There are no known workarounds. |
Affected by 10 other vulnerabilities. |
|
VCID-n6ew-t7g1-33gn
Aliases: CVE-2026-1525 GHSA-2mjp-6q6p-2qxm |
Undici has an HTTP Request/Response Smuggling issue ### 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 upgrade to this version or later. ### Workarounds If upgrading is not immediately possible: 1. **Validate header names**: Ensure no duplicate `Content-Length` headers (case-insensitive) are present before passing headers to undici 2. **Use object format**: Pass headers as a plain object (`{ 'content-length': '123' }`) rather than an array, which naturally deduplicates by key 3. **Sanitize user input**: If headers originate from user input, normalize header names to lowercase and reject duplicates |
Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-ph2p-u33d-8yh3
Aliases: CVE-2026-1527 GHSA-4992-7rv2-5pvq |
Undici has CRLF Injection in undici via `upgrade` option ### 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: ```javascript // lib/dispatcher/client-h1.js:1121 if (upgrade) { header += `connection: upgrade\r\nupgrade: ${upgrade}\r\n` } ``` ### 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: ```javascript function sanitizeUpgrade(value) { if (/[\r\n]/.test(value)) { throw new Error('Invalid upgrade value') } return value } client.request({ upgrade: sanitizeUpgrade(userInput) }) ``` |
Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-rskk-s95c-rfgz
Aliases: CVE-2022-35948 GHSA-f772-66g8-q5h3 |
Nodejs ‘undici’ vulnerable to CRLF Injection via Content-Type ### 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: ``` 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) `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](https://github.com/nodejs/undici/issues) - To make a report, follow the [SECURITY](https://github.com/nodejs/node/blob/HEAD/SECURITY.md) document |
Affected by 13 other vulnerabilities. |
|
VCID-sy2z-sqgk-d7hg
Aliases: CVE-2026-1526 GHSA-vrm6-8vpv-qv8q |
Undici has Unbounded Memory Consumption in WebSocket permessage-deflate Decompression ## Description 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 occurs in native/external memory, bypassing V8 heap limits - No application-level mitigation is possible as decompression occurs before message delivery ### Patches Users should upgrade to fixed versions. ### Workarounds No workaround are possible. |
Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-u8t3-4awy-k3fm
Aliases: CVE-2024-30260 GHSA-m4v8-wqvr-p9f7 |
Undici's Proxy-Authorization header not cleared on cross-origin redirect for dispatch, request, stream, pipeline ### 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 |
Affected by 7 other vulnerabilities. Affected by 8 other vulnerabilities. |
|
VCID-vh17-44d1-kyf7
Aliases: CVE-2023-24807 GHSA-r6ch-mqf9-qc9w |
Regular Expression Denial of Service in Headers 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. |
Affected by 11 other vulnerabilities. |
|
VCID-wqk1-vxt3-j3bb
Aliases: CVE-2022-31150 GHSA-3cvr-822r-rqcc |
undici before v5.8.0 vulnerable to CRLF injection in request headers ### Impact It is possible to inject CRLF sequences into request headers in Undici. ```js 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` ### 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](https://github.com/nodejs/undici/issues) * To make a report, follow the [SECURITY](https://github.com/nodejs/node/blob/HEAD/SECURITY.md) document |
Affected by 15 other vulnerabilities. |
|
VCID-x5np-z1be-m7gq
Aliases: CVE-2022-31151 GHSA-q768-x9m6-m9qp |
undici before v5.8.0 vulnerable to uncleared cookies on cross-host / cross-origin redirect ### 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 https://curl.se/docs/CVE-2022-27776.html ### For more information If you have any questions or comments about this advisory: * Open an issue in [undici repository](https://github.com/nodejs/undici/issues) * To make a report, follow the [SECURITY](https://github.com/nodejs/node/blob/HEAD/SECURITY.md) document |
Affected by 15 other vulnerabilities. |
|
VCID-xx5u-7mmp-akfs
Aliases: CVE-2024-24758 GHSA-3787-6prv-h9w3 |
Undici proxy-authorization header not cleared on cross-origin redirect in fetch ### 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 |
Affected by 9 other vulnerabilities. Affected by 10 other vulnerabilities. |
|
VCID-z653-vqsc-euer
Aliases: CVE-2024-30261 GHSA-9qxr-qj54-h672 |
Undici's fetch with integrity option is too lax when algorithm is specified but hash value is in incorrect ### 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 |
Affected by 7 other vulnerabilities. Affected by 8 other vulnerabilities. |
|
VCID-zb3h-efqz-dff3
Aliases: CVE-2026-22036 GHSA-g9mf-h72j-4rw9 |
Undici has an unbounded decompression chain in HTTP responses on Node.js Fetch API via Content-Encoding leads to resource exhaustion ### 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 |
Affected by 5 other vulnerabilities. Affected by 6 other vulnerabilities. |
| Vulnerability | Summary | Aliases |
|---|---|---|
| This package is not known to fix vulnerabilities. | ||