Update dependency undici to v6.28.0 [SECURITY]

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
undici (source)	6.25.0 → 6.28.0

---

undici vulnerable to HTTP header injection via Set-Cookie percent-decoding

CVE-2026-9679 / GHSA-p88m-4jfj-68fv

More information

Details

Impact

undici's cookie parser in parseSetCookie percent-decodes cookie values via qsUnescape, turning encoded sequences like %0D%0A, %00, %3B, and %3D into their literal byte equivalents. RFC 6265 §5.4 does not specify any decoding and browsers do not decode either.

Applications that parse a Set-Cookie header and then forward the parsed value into a response header (proxies, middleware, SSR frameworks) become vulnerable to HTTP response header injection: an attacker-controlled upstream can inject arbitrary Set-Cookie, Location, or Cache-Control headers into the application's downstream response, enabling session fixation, open redirect, or cache poisoning.

Affected applications are those that use undici's cookie parsing (parseSetCookie, parseCookie, getSetCookies) and forward the parsed cookie value into a response header.

This was introduced in undici 7.0.0 via #​3789.

Patches

Upgrade to undici v6.27.0, v7.28.0 or v8.5.0.

Workarounds

If upgrade is not immediately possible, do not forward values returned by parseSetCookie/parseCookie/getSetCookies directly into response headers; sanitize the value first to strip or reject CR, LF, NUL, ;, and = bytes.

Severity

• CVSS Score: 5.9 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N

References

• https://github.com/nodejs/undici/security/advisories/GHSA-p88m-4jfj-68fv
• https://nvd.nist.gov/vuln/detail/CVE-2026-9679
• https://cna.openjsf.org/security-advisories.html
• https://github.com/advisories/GHSA-p88m-4jfj-68fv

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

undici vulnerable to HTTP response queue poisoning via keep-alive socket reuse

CVE-2026-6733 / GHSA-35p6-xmwp-9g52

More information

Details

Impact

Undici's HTTP/1.1 client is vulnerable to response queue poisoning on reused keep-alive sockets. An attacker-controlled upstream server can inject an unsolicited HTTP/1.1 response onto an idle socket after a request completes. When the client dispatches the next request on that socket, it associates the injected response with the new request, causing responses to be delivered to the wrong requests.

This requires an attacker-controlled or compromised upstream HTTP/1.1 server and keep-alive connection reuse.

Patches

Upgrade to undici v6.27.0, v7.28.0 or v8.5.0.

Workarounds

Disable keep-alive connection reuse by setting keepAliveTimeout: 0 on the Client or Pool.

Severity

• CVSS Score: 3.7 / 10 (Low)
• Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N

References

• https://github.com/nodejs/undici/security/advisories/GHSA-35p6-xmwp-9g52
• https://nvd.nist.gov/vuln/detail/CVE-2026-6733
• https://hackerone.com/reports/3582376
• https://cna.openjsf.org/security-advisories.html
• https://github.com/nodejs/undici/commit/6ea54ef8c4051e95bb68c89d4a5c9274fe6fbb4b
• https://github.com/nodejs/undici/releases/tag/v6.27.0
• https://github.com/nodejs/undici/releases/tag/v7.28.0
• https://github.com/nodejs/undici/releases/tag/v8.5.0
• https://github.com/advisories/GHSA-35p6-xmwp-9g52

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

undici vulnerable to Set-Cookie SameSite attribute downgrade via permissive substring matching

CVE-2026-11525 / GHSA-g8m3-5g58-fq7m

More information

Details

Impact

When undici parses a Set-Cookie header, it accepts any SameSite attribute value that contains Strict, Lax, or None as a substring, rather than the case-insensitive exact match specified by RFC 6265. Non-spec values are silently mapped to one of the three standard tokens:

• SameSite=NoneOfYourBusiness is parsed as None, the most permissive setting.
• SameSite=StrictLax is parsed as Lax, a downgrade from Strict.

Affected applications are those that consume Set-Cookie headers from server responses (for example via undici's fetch or proxy code paths) and then forward or rely on the parsed sameSite attribute. A malicious or non-compliant server can coerce the consumer's view of a cookie's SameSite policy to a weaker value, silently degrading the SameSite enforcement the cookie is supposed to provide.

This was introduced in undici 5.15.0 when the cookies feature was added.

Patches

Upgrade to undici v6.27.0, v7.28.0 or v8.5.0.

Workarounds

After parsing a Set-Cookie header, validate that the resulting sameSite attribute is one of 'Strict', 'Lax', or 'None' (exact, case-insensitive) before forwarding or relying on it.

Severity

• CVSS Score: 3.7 / 10 (Low)
• Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N

References

• https://github.com/nodejs/undici/security/advisories/GHSA-g8m3-5g58-fq7m
• https://nvd.nist.gov/vuln/detail/CVE-2026-11525
• https://cna.openjsf.org/security-advisories.html
• https://github.com/advisories/GHSA-g8m3-5g58-fq7m

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

undici vulnerable to CRLF Injection via blob-like body 'type' property

CVE-2026-15157 / GHSA-m8rv-5g2x-5cg5

More information

Details

Impact

When an application passes a duck-typed blob-like body to undici's HTTP/1.1 dispatcher (via request(), stream(), pipeline(), or dispatch()) with a .type derived from untrusted input, an attacker can inject CRLF sequences (\r\n) to append arbitrary HTTP headers and potentially smuggle a second request past the upstream.

The vulnerable branch in lib/dispatcher/client-h1.js pushes body.type directly into the outgoing headers with no validation, while every other header path in undici goes through isValidHeaderValue():

} else if (util.isBlobLike(body) && request.contentType == null && body.type) {
  headers.push('content-type', body.type)  // bypasses isValidHeaderValue()
}

The bug requires a hand-rolled duck-typed blob object or a Blob subclass with a controlled .type. Native Blob is safe because its constructor strips CRLF from .type. fetch() is unaffected because it validates via the Headers class. Ecosystem consumers that build duck-typed blob shapes from user input include form-data-encoder, formdata-polyfill, and formdata-node.

Same defect class as CVE-2022-35948 (explicit content-type sink, fixed in undici 5.8.2) and CVE-2026-1527 (upgrade option sink, fixed in 6.24.0 / 7.24.0), both closed by adding isValidHeaderValue() on their respective sinks. This branch was missed.

Patches

Patched in undici v6.28.0, v7.29.0, and v8.9.0. Users should upgrade to one of these versions or later.

Workarounds

• Set an explicit, validated content-type header on the request options (skips the vulnerable branch).
• Use a native Blob (or fetch-blob) instead of a hand-rolled duck-typed object.
• Reject control characters in the MIME type before assigning it to .type.
• Use fetch() instead of the non-fetch APIs.

Severity

• CVSS Score: 4.2 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N

References

• https://github.com/nodejs/undici/security/advisories/GHSA-m8rv-5g2x-5cg5
• https://nvd.nist.gov/vuln/detail/CVE-2026-15157
• https://github.com/nodejs/undici/commit/33928bc24f742ea8422ed90d17f2e0cc83e4d09d
• https://github.com/nodejs/undici/commit/740a0b7c173cb4a83a5b693e96e8f3a116cfc400
• https://github.com/nodejs/undici/commit/7d3cf924c262c486bc77f951348f4e5c847b7b42
• https://cna.openjsf.org/security-advisories.html
• https://github.com/nodejs/undici/releases/tag/v6.28.0
• https://github.com/nodejs/undici/releases/tag/v7.29.0
• https://github.com/nodejs/undici/releases/tag/v8.9.0
• https://github.com/advisories/GHSA-m8rv-5g2x-5cg5

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

undici vulnerable to downstream response desynchronization via retry interceptor

CVE-2026-16728 / GHSA-8xcm-r25x-g524

More information

Details

Impact

Undici's interceptors.retry() can deliver a response whose body length does not match the Content-Length header exposed to the application after a retry or resume of a partial response. Applications that use interceptors.retry() and forward upstream response headers and bodies downstream, for example proxy or gateway applications, may emit an invalid HTTP response with a stale Content-Length header. This can lead to downstream response desynchronization, connection hangs, or response corruption in clients or intermediaries that rely on the forwarded framing metadata.

A malicious or faulty upstream can respond to a range request with a 206 Partial Content response such as:

Content-Range: bytes 0-99/300
Content-Length: 300

and then send only 99 bytes before closing the socket. interceptors.retry() can then retry with Range: bytes=99-99, receive the final byte, and deliver a 100-byte body to the application while the response headers still contain Content-Length: 300 from the first response.

The bug requires interceptors.retry() to be enabled, an upstream that returns a partial response with a mismatched framing header, and a downstream forwarder that does not remove or recalculate Content-Length.

Patches

Patched in undici v6.28.0, v7.29.0, and v8.9.0. Users should upgrade to one of these versions or later.

Workarounds

• Disable interceptors.retry() for untrusted upstreams.
• Remove or recalculate Content-Length before forwarding a response body assembled or transformed by Undici.

Severity

• CVSS Score: 4.8 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N

References

• https://github.com/nodejs/undici/security/advisories/GHSA-8xcm-r25x-g524
• https://nvd.nist.gov/vuln/detail/CVE-2026-16728
• https://github.com/nodejs/undici/commit/1b5a5312c3a7d7a30c31bf0d000b39a8a2531e1c
• https://github.com/nodejs/undici/commit/2b3f749336d356bbbc50192f87f6cf7bc714721a
• https://github.com/nodejs/undici/commit/4a9dafb16ff43880cf590e6d9c2aeee25fbff6d7
• https://github.com/nodejs/undici/commit/4fd5a0c61e627f928b7003adc4ffe1e55ec63420
• https://github.com/nodejs/undici/commit/cba3a52ac2e7abcc4e656d82af8579ea82c2bb9e
• https://github.com/nodejs/undici/commit/e11a68ed4ff345c79402476f7a00d473443e318d
• https://hackerone.com/reports/3828685
• https://cna.openjsf.org/security-advisories.html
• https://github.com/nodejs/undici/releases/tag/v6.28.0
• https://github.com/nodejs/undici/releases/tag/v7.29.0
• https://github.com/nodejs/undici/releases/tag/v8.9.0
• https://github.com/advisories/GHSA-8xcm-r25x-g524

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

undici vulnerable to cookie attribute injection via unsanitized domain and unparsed setCookie fields

CVE-2026-16729 / GHSA-v3r7-h72x-cjcm

More information

Details

Impact

The setCookie function has two attribute injection paths. validateCookieDomain does not reject semicolons (validateCookiePath already does at 0x3B), so a domain value like example.com; SameSite=None lands verbatim as Domain=example.com; SameSite=None. The unparsed array's loop only checks each entry contains = and does not sanitize values, so an entry like X-Custom=val; HttpOnly lands unchanged, injecting HttpOnly without the caller setting cookie.httpOnly = true.

Applications that pass user-controlled input to these fields, typically multi-tenant or reverse-proxy servers that scope session cookies to a tenant-supplied domain, can have SameSite CSRF protections bypassed, Secure or HttpOnly forced or stripped, or the intended SameSite tier overridden.

Patches

Patched in undici v6.28.0, v7.29.0, and v8.9.0.

Workarounds

• Sanitize domain values against the RFC 1034 letter-digit-hyphen set before passing to setCookie.
• Do not pass user-controlled data to the unparsed field.

Severity

• CVSS Score: 4.8 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N

References

• https://github.com/nodejs/undici/security/advisories/GHSA-v3r7-h72x-cjcm
• https://nvd.nist.gov/vuln/detail/CVE-2026-16729
• https://github.com/nodejs/undici/commit/10d93fc332f2c8c161982dec3833201de29891b5
• https://github.com/nodejs/undici/commit/3bf91ddb493e853957f3a58e155326a668ab8aef
• https://github.com/nodejs/undici/commit/af7484043ee075a6f216da0ad77e1dac55199235
• https://cna.openjsf.org/security-advisories.html
• https://github.com/nodejs/undici/releases/tag/v6.28.0
• https://github.com/nodejs/undici/releases/tag/v7.29.0
• https://github.com/nodejs/undici/releases/tag/v8.9.0
• https://github.com/advisories/GHSA-v3r7-h72x-cjcm

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

Release Notes

nodejs/undici (undici)

v6.28.0

Compare Source

Full Changelog: nodejs/undici@v6.27.0...v6.28.0

v6.27.0

Compare Source

⚠️ Security Release

This release line addresses 4 security advisories.

Action required: Upgrade to undici 6.27.0 or later.

npm install undici@^6.27.0

Note on patched version: the v6 fixes shipped in v6.27.0, not 6.26.0
— v6.26.0 contains only the chunked-EOF fix (#​5308) and the version bump, none
of the security fixes below.

The v6 line is not affected by the SOCKS5 advisories (GHSA-vmh5-mc38-953g,
GHSA-hm92-r4w5-c3mj), the shared-cache disclosure (GHSA-pr7r-676h-xcf6), or the
8.x-only WebSocket regression (GHSA-38rv-x7px-6hhq).

Summary

Advisory	CVE	Severity (CVSS)	Fixed in	Fix commit
GHSA-vxpw-j846-p89q	CVE-2026-12151	High (7.5)	6.27.0	b7f252e7
GHSA-p88m-4jfj-68fv	CVE-2026-9679	Moderate (5.9)	6.27.0	25efa447
GHSA-g8m3-5g58-fq7m	CVE-2026-11525	Low (3.7)	6.27.0	25efa447
GHSA-35p6-xmwp-9g52	CVE-2026-6733	Low (3.7)	6.27.0	f4c31d60

---

High severity

WebSocket DoS via fragment count bypass — CVE-2026-12151

GHSA-vxpw-j846-p89q · CWE-400, CWE-770
Fix: b7f252e7 Backport WebSocket maxPayloadSize fixes (#​5423, backported to v6 in #​5428)

A malicious WebSocket server can stream a large number of small or empty
continuation frames. Undici enforced a limit on cumulative payload size but did
not limit the number of fragments per message, leading to unbounded memory
growth and denial of service. All releases from 6.17.0 onward are affected.

• Affected: applications using new WebSocket(...) or WebSocketStream
  against untrusted endpoints.
• Workaround: none — upgrade is required.

---

Moderate severity

HTTP header injection via Set-Cookie percent-decoding — CVE-2026-9679

GHSA-p88m-4jfj-68fv · CWE-93
Fix: 25efa447 fix(cookies): preserve values and parse SameSite strictly

parseSetCookie applied percent-decoding to cookie values, turning encoded
sequences like %0D%0A and %00 into literal bytes, contrary to RFC 6265 §5.4
and browser behavior. Applications forwarding parsed Set-Cookie values into
response headers were exposed to header injection, enabling session fixation,
open redirects, and cache poisoning.

• Workaround: sanitize values before forwarding — strip or reject CR, LF,
  NUL, ;, and =.

---

Low severity

Set-Cookie SameSite attribute downgrade — CVE-2026-11525

GHSA-g8m3-5g58-fq7m · CWE-183
Fix: 25efa447 fix(cookies): preserve values and parse SameSite strictly

The cookie parser accepted SameSite values containing Strict, Lax, or
None as substrings rather than requiring exact matches per RFC 6265. Values
like SameSite=NoneOfYourBusiness parsed as None, and SameSite=StrictLax
parsed as Lax, silently weakening cookie security policies for apps that
forward parsed attributes.

HTTP response queue poisoning via keep-alive socket reuse — CVE-2026-6733

GHSA-35p6-xmwp-9g52 · CWE-367 (TOCTOU race condition)
Fix: f4c31d60 fix: guard idle socket validation to skip fresh sockets (#​5400)

An attacker controlling an upstream HTTP/1.1 server could inject unsolicited
responses onto idle keep-alive sockets. On socket reuse, the injected response
was associated with a new request, delivering responses to the wrong requests.

• Requirements: attacker-controlled/compromised upstream and active
  keep-alive reuse.
• Workaround: disable keep-alive reuse with keepAliveTimeout: 0 on the
  Client or Pool.

---

Release contents & deliberate backports

v6.27.0 is a security-only release — every change in it is one of the fixes
above, backported to the v6.x maintenance line on purpose:

• #5428 — backport of the WebSocket maxPayloadSize fragment-count / cumulative-size limits to v6.x (CVE-2026-12151; this is the v6 counterpart of the v7 backport #​5423).
• #5400 — idle-socket-validation fix for the queue-poisoning issue (CVE-2026-6733).

The cookie fix (25efa447,
covering both CVE-2026-9679 and CVE-2026-11525) was applied directly to the v6.x
branch. Full changelog:
v6.26.0...v6.27.0.

---

Credits

Per-advisory credits (as recorded in each GHSA):

• CVE-2026-12151 — reported by @​lpinca & @​Nadav0077; reviewed by @​UlisesGascon.
• CVE-2026-9679 — reported by @​tndud042713; fixed by @​mcollina; reviewed by @​KhafraDev & @​UlisesGascon.
• CVE-2026-11525 — fixed by @​mcollina; reviewed by @​UlisesGascon.
• CVE-2026-6733 — fixed by @​mcollina; verified by @​UlisesGascon.

v6.26.0

Compare Source

What's Changed

• fix: validate EOF for chunked h1 responses by @​mcollina in #​5308

Full Changelog: nodejs/undici@v6.25.0...v6.26.0

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, 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.