chore(deps): update dependency undici@>=5.0.0 to ^5.29.0 [security]

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
undici@>=5.0.0 (source)	^5.28.5 → ^5.29.0

GitHub Vulnerability Alerts

CVE-2026-22036

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
• GHSA-gm62-xv2j-4w53
• https://curl.se/docs/CVE-2022-32206.html

CVE-2026-1528

Impact

A server can reply with a WebSocket frame using the 64-bit length form and an extremely large length. undici's ByteParser overflows internal math, ends up in an invalid state, and throws a fatal TypeError that terminates the process.

Patches

Patched in the undici version v7.24.0 and v6.24.0. Users should upgrade to this version or later.

Workarounds

There are no workarounds.

CVE-2026-1525

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

CVE-2026-1527

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:

// 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:

function sanitizeUpgrade(value) {
  if (/[\r\n]/.test(value)) {
    throw new Error('Invalid upgrade value')
  }
  return value
}

client.request({
  upgrade: sanitizeUpgrade(userInput)
})

---

Release Notes

nodejs/undici (undici@>=5.0.0)

v5.29.0

Compare Source

What's Changed

• Fix tests in v5.x for Node 20 by @​mcollina in #​4104
• Removed clients with unrecoverable errors from the Pool #​4088

Full Changelog: nodejs/undici@v5.28.5...v5.29.0

---

Configuration

📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[netlify]

✅ Deploy Preview for brilliant-pasca-3e80ec canceled.

Name	Link
🔨 Latest commit	f94e384
🔍 Latest deploy log	https://app.netlify.com/projects/brilliant-pasca-3e80ec/deploys/69a9c0544d0ae50007836d28

[github-actions]

🚀 Performance Test Results

Test Configuration:

• VUs: 4
• Duration: 1m0s

Test Metrics:

• Requests/s: 46.71
• Iterations/s: 15.58
• Failed Requests: 0.00% (0 of 2810)

📜 Logs

> performance@1.0.0 run-tests:testenv /home/runner/work/rafiki/rafiki/test/performance
> ./scripts/run-tests.sh -e test "-k" "-q" "--vus" "4" "--duration" "1m"

Cloud Nine GraphQL API is up: http://localhost:3101/graphql
Cloud Nine Wallet Address is up: http://localhost:3100/
Happy Life Bank Address is up: http://localhost:4100/
cloud-nine-wallet-test-backend already set
cloud-nine-wallet-test-auth already set
happy-life-bank-test-backend already set
happy-life-bank-test-auth already set
     data_received..................: 1.0 MB 17 kB/s
     data_sent......................: 2.2 MB 36 kB/s
     http_req_blocked...............: avg=6.76µs   min=2.26µs  med=5.39µs   max=486.35µs p(90)=6.68µs   p(95)=7.34µs  
     http_req_connecting............: avg=416ns    min=0s      med=0s       max=415.93µs p(90)=0s       p(95)=0s      
     http_req_duration..............: avg=85.04ms  min=8.5ms   med=69.51ms  max=580.83ms p(90)=143.69ms p(95)=159.67ms
       { expected_response:true }...: avg=85.04ms  min=8.5ms   med=69.51ms  max=580.83ms p(90)=143.69ms p(95)=159.67ms
     http_req_failed................: 0.00%  ✓ 0         ✗ 2810
     http_req_receiving.............: avg=78.28µs  min=24.98µs med=66.26µs  max=4.31ms   p(90)=92.9µs   p(95)=110.05µs
     http_req_sending...............: avg=33.56µs  min=11.8µs  med=25.5µs   max=2.76ms   p(90)=35.88µs  p(95)=44.12µs 
     http_req_tls_handshaking.......: avg=0s       min=0s      med=0s       max=0s       p(90)=0s       p(95)=0s      
     http_req_waiting...............: avg=84.93ms  min=8.34ms  med=69.43ms  max=580.74ms p(90)=143.62ms p(95)=159.58ms
     http_reqs......................: 2810   46.712023/s
     iteration_duration.............: avg=256.56ms min=170.5ms med=245.49ms max=944.51ms p(90)=299.3ms  p(95)=327.23ms
     iterations.....................: 937    15.576216/s
     vus............................: 4      min=4       max=4 
     vus_max........................: 4      min=4       max=4