🚨 [security] Update undici 4.7.0 → 7.16.0 (major)

[depfu]

---

Welcome to Depfu 👋

This is one of the first three pull requests with dependency updates we've sent your way. We tried to start with a few easy patch-level updates. Hopefully your tests will pass and you can merge this pull request without too much risk. This should give you an idea how Depfu works in general.

After you merge your first pull request, we'll send you a few more. We'll never open more than seven PRs at the same time so you're not getting overwhelmed with updates.

Let us know if you have any questions. Thanks so much for giving Depfu a try!

---

---

🚨 Your current dependencies have known security vulnerabilities 🚨

This dependency update fixes known security vulnerabilities. Please see the details below and assess their impact carefully. We recommend to merge and deploy this as soon as possible!

---

Here is everything you need to know about this upgrade. Please take a good look at what changed and the test results before merging this pull request.

What changed?

✳️ undici (4.7.0 → 7.16.0) · Repo

Security Advisories 🚨

🚨 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 #4088.

Workarounds

If a webhook fails, avoid keep calling it repeatedly.

References

Reported as: #3895

🚨 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 #4088.

Workarounds

If a webhook fails, avoid keep calling it repeatedly.

References

Reported as: #3895

🚨 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 #4088.

Workarounds

If a webhook fails, avoid keep calling it repeatedly.

References

Reported as: #3895

🚨 Use of Insufficiently Random Values in undici

Impact

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.

Patches

This is fixed in 5.28.5; 6.21.1; 7.2.3.

Workarounds

Do not issue multipart requests to attacker controlled servers.

References

• https://hackerone.com/reports/2913312
• https://blog.securityevaluators.com/hacking-the-javascript-lottery-80cc437e3b7f

🚨 Use of Insufficiently Random Values in undici

Impact

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.

Patches

This is fixed in 5.28.5; 6.21.1; 7.2.3.

Workarounds

Do not issue multipart requests to attacker controlled servers.

References

• https://hackerone.com/reports/2913312
• https://blog.securityevaluators.com/hacking-the-javascript-lottery-80cc437e3b7f

🚨 Use of Insufficiently Random Values in undici

Impact

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.

Patches

This is fixed in 5.28.5; 6.21.1; 7.2.3.

Workarounds

Do not issue multipart requests to attacker controlled servers.

References

• https://hackerone.com/reports/2913312
• https://blog.securityevaluators.com/hacking-the-javascript-lottery-80cc437e3b7f

🚨 Undici vulnerable to data leak when using response.arrayBuffer()

Impact

Depending on network and process conditions of a fetch() request, response.arrayBuffer() might include portion of memory from the Node.js process.

Patches

This has been patched in v6.19.2.

Workarounds

There are no known workaround.

References

#3337
#3328
#3338
f979ec3

🚨 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 6805746.
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
• GHSA-3787-6prv-h9w3

🚨 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 6805746.
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
• GHSA-3787-6prv-h9w3

🚨 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 d542b8c.
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

🚨 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 d542b8c.
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

🚨 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
• GHSA-wqq4-5wpv-mx2g

🚨 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
• GHSA-wqq4-5wpv-mx2g

🚨 fetch(url) leads to a memory leak in undici

Impact

Calling fetch(url) and not consuming the incoming body ((or consuming it very slowing) will lead to a memory leak.

Patches

Patched in v6.6.1

Workarounds

Make sure to always consume the incoming body.

🚨 Undici's cookie header not cleared on cross-origin redirect in fetch

Impact

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.

Patches

This was patched in e041de359221ebeae04c469e8aff4145764e6d76, which is included in version 5.26.2.

🚨 CRLF Injection in Nodejs ‘undici’ via host

Impact

undici library does not protect host HTTP header from CRLF injection vulnerabilities.

Patches

This issue was patched in Undici v5.19.1.

Workarounds

Sanitize the headers.host string before passing to undici.

References

Reported at https://hackerone.com/reports/1820955.

Credits

Thank you to Zhipeng Zhang (@timon8) for reporting this vulnerability.

🚨 Regular Expression Denial of Service in Headers

Impact

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.

Patches

This vulnerability was patched in v5.19.1.

Workarounds

There is no workaround. Please update to an unaffected version.

References

• https://hackerone.com/bugs?report_id=1784449

Credits

Carter Snook reported this vulnerability.

🚨 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
• To make a report, follow the SECURITY document

🚨 `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

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
• To make a report, follow the SECURITY document

🚨 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 #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 #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
• To make a report, follow the SECURITY document

🚨 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.

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
• To make a report, follow the SECURITY document

🚨 ProxyAgent vulnerable to MITM

Description

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 the time of writing, the only workaround is to not use ProxyAgent as a dispatcher for TLS Connections.

Release Notes

Too many releases to show here. View the full release notes.

Commits

See the full diff on Github. The new version differs by 63 commits:

• Bumped v7.16.0 (#4532)
• fix: make error symbols non enumerable (#4531)
• Disable SIMD for PPC64 architecture, add UNDICI_NO_WASM_SIMD env to facilitate testing (#4530)
• example: use metcoders https-pem for the example (#4436)
• fix: shell command built from environment values (#4392)
• fix: wpt should use master branch (#4524)
• refactor: parseHttpDate (#4421)
• websocket: always emit error event (#4521)
• fetch: process content-encoding header only if relevant (#4496)
• wpt: properly handle write permissions errors in wpt-runner setup (#4518)
• feat: Support for capping the number of origins in Agent (#4365)
• ci: fine grained test nodejs workflow (#4516)
• chore: make also cache-tests integrated as a submodule (#4517)
• change webidl attribute to bitwise flag (#4505)
• chore: use `[]` instead of new Array(0) (#4435)
• chore: refactor workflows (#4513)
• chore: use lowercase filenames (#4514)
• fix(h2): adjust :scheme on h2 requests (#4454)
• build(deps): bump codecov/codecov-action from 5.4.3 to 5.5.0 (#4508)
• build(deps): bump github/codeql-action from 3.29.7 to 3.30.0 (#4510)
• test: use faketimers for test/client-keep-alive (#4499)
• fix writing to websocketstream with SharedArrayBuffer/SharedArrayBuffer view (#4504)
• build(deps): bump actions/dependency-review-action from 4.7.1 to 4.7.3 (#4509)
• build(deps): bump actions/checkout from 4 to 5 (#4507)
• test: another try to fix flaky macos and node 20 (#4490)
• real wpt test server (#4486)
• webidl: fix existing and add missing buffer source converters (#4503)
• test (websocket): speed up test/websocket/issue-2679.js (#4501)
• fix: implement proper stale-while-revalidate behavior per RFC 5861 (#4492)
• test: skip flaky encoding test on macos and node20 (#4497)
• fix: remove useless catch in client-h1.js (#4481)
• test (eventsource): refactor tests for eventsource, speed them up (#4493)
• test (pool.js): fix flakyness of clientTtl test (#4494)
• fix: improve validation of IP addresses as trustworthy, correct ipv check (#4489)
• fix: deflake cache-fastimers-fix.js (#4491)
• fix: no-referrer-when-downgrade in determineRequestsReferrer should return referrerURL (#4482)
• test: investigate further macos flakyness (#4468)
• lint: avoid unintented use of globals in code and tests, improve test for installing/overwriting globals (#4478)
• chore: pool and dispatcherbase dont need constructor, use no array helper functions (#4477)
• fix: remove unused ResponseStatusCodeError (#4473)
• fix: buildAndValidateMockOptions should always get an object passed and always return an object (#4479)
• chore: FixedQueue does not need special constructor (#4476)
• chore: call super() after type checks (#4475)
• feat: make UndiciErrors reliable to instanceof (#4472)
• eventsource: remove promise for #reconnect method (#4469)
• fix: avoid instanceof MockNotMatchedError (#4474)
• fix: catch synchronous errors in request callbacks (#4443)
• perf (fetch): use less promises for ReadableStream (#4457)
• test: remove skip checks for existance of global available Blob and File (#4460)
• test: remove skip check for long-lived-abort-controller test (was flaky 10 months ago) (#4465)
• perf: avoid intermediate promise on `BodyReadable.dump` (#4459)
• test: remove obsolete < node v18 test case (#4461)
• test: investigate macos failing (#4467)
• test: remove skip check for AbortSignal.timeout, as it exists since node18 (#4464)
• test: fix IPv6 skip check for test/client.js (#4466)
• test: cache store tests should properly be skipped (#4463)
• fix(#4451): implement http2 cookie support (#4453)
• fetch: remove promise in exported fetch (#4452)
• perf: make `client.connect()` sync (#4455)
• fetch: make consumeBody sync (#4449)
• fix: remove async on `[kClose]` and `[kDestroy]`, only return Promise (#4450)
• fetch: instantiate readableStream in extractBody with sync methods (#4350)
• Drop npm token, use OIDC instead (#4447)

---

Depfu will automatically keep this PR conflict-free, as long as you don't add any commits to this branch yourself. You can also trigger a rebase manually by commenting with @depfu rebase.

All Depfu comment commands

@​depfu rebase

Rebases against your default branch and redoes this update

@​depfu recreate

Recreates this PR, overwriting any edits that you've made to it

@​depfu merge

Merges this PR once your tests are passing and conflicts are resolved

@​depfu cancel merge

Cancels automatic merging of this PR

@​depfu close

Closes this PR and deletes the branch

@​depfu reopen

Restores the branch and reopens this PR (if it's closed)

@​depfu pause

Ignores all future updates for this dependency and closes this PR

@​depfu pause [minor|major]

Ignores all future minor/major updates for this dependency and closes this PR

@​depfu resume

Future versions of this dependency will create PRs again (leaves this PR as is)

[depfu]

Closed in favor of #231.