You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Undici's cache interceptor incorrectly classifies some responses as cacheable when the upstream Cache-Control header uses whitespace-padded qualified private or no-cache field names such as private=" authorization" or no-cache="\tauthorization". The parser preserves the surrounding whitespace, so later comparisons against the literal authorization field name fail and the response is stored.
In shared-cache mode, this allows a response containing one user's authenticated data to be served from cache to a subsequent caller, including an unauthenticated caller, when both requests resolve to the same cache key.
Affected applications are those that explicitly enable the cache interceptor (interceptors.cache()) in shared mode, forward Authorization headers upstream, and receive cacheable responses with non-canonical qualified private or no-cache directives.
Patches
Upgrade to undici v7.28.0 or v8.5.0.
Workarounds
If upgrade is not immediately possible, disable shared-cache mode for traffic that includes Authorization headers, avoid caching responses to authenticated requests, or add Vary: Authorization upstream.
undici's ProxyAgent silently drops the requestTls option when configured with a SOCKS5 proxy URI (socks5:// or socks://). The target HTTPS connection through the SOCKS5 tunnel falls back to Node's default trust store, ignoring user-configured ca, cert, key, rejectUnauthorized, and servername settings.
Applications that pin to an internal or corporate CA via requestTls.ca will, when their proxy URI is SOCKS5, get the default Mozilla CA bundle as the trust anchor instead. Any cert signed by any publicly-trusted CA for the target hostname is accepted, breaking the intended pin and enabling MITM read and tamper of the HTTPS exchange.
Affected applications are those that use undici's ProxyAgent (or Socks5ProxyAgent directly) with SOCKS5 AND rely on requestTls for TLS scope restriction. The bug was introduced in undici 7.23.0 when SOCKS5 support was added.
Patches
Upgrade to undici v7.28.0 or v8.5.0.
Workarounds
No workaround is available within the SOCKS5 path. If a SOCKS5 proxy with TLS scope restriction is required and an upgrade is not yet possible, route the traffic through an HTTP-proxy ProxyAgent instead, where requestTls is honored correctly.
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.
When using Socks5ProxyAgent, undici reuses a single connection pool across different origins without verifying that the pool's origin matches the requested origin. All requests are dispatched through the pool connected to the first origin, regardless of the intended destination.
This causes cross-origin request routing: credentials and request data intended for origin B are sent to origin A, responses from the wrong origin are trusted, and HTTPS requests may be silently downgraded to HTTP.
Impacted users are applications that use Socks5ProxyAgent (directly or via setGlobalDispatcher) and make requests to more than one origin.
This was introduced in undici 7.23.0 via #4385 and affects all versions through 8.1.0.
Patches
Upgrade to undici v7.28.0 or v8.2.0
Workarounds
Use a separate Socks5ProxyAgent instance per origin, or avoid using Socks5ProxyAgent with multiple origins.
The undici WebSocket client enforces maxPayloadSize on the cumulative byte count of fragments in a message but does not enforce a limit on the number of fragments. A malicious WebSocket server can stream many small or empty continuation frames that each pass per-frame and cumulative-size validation, collectively causing unbounded memory growth in the client process. The result is memory exhaustion and a denial of service.
Affected applications are those using the undici WebSocket client (new WebSocket(...)) or the WebSocketStream API that can be induced to connect to an attacker-controlled or compromised WebSocket endpoint.
All releases starting at undici 6.17.0 are affected.
Patches
Upgrade to undici v6.27.0, v7.28.0 or v8.5.0.
Workarounds
No workaround is available. The fix must be applied through an upgrade.
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.
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.
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.
Two issues in undici's cache interceptor, both fixed by the same patch on lib/util/cache.js:
Shared-cache disclosure: Responses with malformed qualified Cache-Control: private directives such as private="" or private="," can be incorrectly stored in the default shared cache, then served to a later caller with the same cache key.
Parse-time crash: Mixed unqualified-and-qualified private directives in the same header (such as public, max-age=60, private, private="hdr") cause an uncaught TypeError in the cache-control parser, terminating the request.
Impact
Shared-cache disclosure
Applications using interceptors.cache() in shared mode may cache a user-specific response and serve it to a later caller with the same cache key. This can disclose private response bodies and headers, including Set-Cookie.
Required conditions:
the cache interceptor is enabled in shared mode, including the default configuration;
an upstream returns a malformed directive such as Cache-Control: public, max-age=300, private="";
another request later matches the same cache key, without a separating Vary header.
Parse-time crash
Applications using interceptors.cache() against an upstream that returns a Cache-Control header combining unqualified private with qualified private="..." see an uncaught TypeError: output.private.concat is not a function during response handling. The request rejects; depending on the consumer's error handling, the process may exit.
Details
private="" is parsed as { private: [''] }. The shared-cache guard only rejects private === true, so the response can be stored. When served from cache, the previous user's body and headers may be returned to a different user.
For the crash variant, an unqualified private directive sets output.private = true, then a subsequent qualified private="hdr" directive attempts output.private.concat(['hdr']), which throws because boolean has no concat method.
The patch routes the qualified-directive path through a shared helper that normalizes empty-after-trim arrays to true and preserves existing true values, closing both vectors.
Patches
Upgrade to undici 7.29.0 or 8.9.0. Both releases fix the qualified private directive handling that caused the shared-cache storage and the parser crash.
Workarounds
Until patched, avoid shared interceptors.cache() for user-specific responses, use type: 'private', or disable caching for affected origins.
Credit
Disclosure variant reported by @h0rk1p via HackerOne report #3817497.
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/300Content-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.
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.
Undici's cache interceptor mishandles optional whitespace (OWS) placed around the = of a qualified no-cache or private Cache-Control directive, such as no-cache ="authorization" (OWS before =) or no-cache= "authorization" (OWS after =). The parser either drops the directive entirely or stores a field name with literal quote characters, so the downstream cache decisions do not recognize the qualification and the response is stored.
In shared-cache mode, this allows a response containing one user's authenticated data to be served from cache to a subsequent caller, including an unauthenticated caller, when both requests resolve to the same cache key. The impact class is identical to CVE-2026-9678 (GHSA-pr7r-676h-xcf6); this advisory covers the whitespace-around-= bypass that the earlier fix did not normalize.
Affected applications are those that explicitly enable the cache interceptor (interceptors.cache()) in shared mode, forward Authorization headers upstream, and receive cacheable responses with qualified private or no-cache directives whose field-name list is padded with OWS around the =.
Patches
Upgrade to undici v7.29.0 or v8.9.0.
Workarounds
If upgrade is not immediately possible, disable shared-cache mode for traffic that includes Authorization headers, avoid caching responses to authenticated requests, or add Vary: Authorization upstream.
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():
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.
Note on GHSA-hm92-r4w5-c3mj: this fix shipped in v7.28.0, not the
earlier 7.2x line — the vulnerable single-pool code was still present through v7.27.2. The per-origin pool fix is 3805b8f8 (#5041).
WebSocket DoS via fragment count bypass — CVE-2026-12151
GHSA-vxpw-j846-p89q · CWE-400, CWE-770 Fix:8cb10f98websocket: limit the number of fragments in a message (part of backport a027a4a0Backport WebSocket maxPayloadSize fixes to v7.x, #5423)
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.
Affected: applications using new WebSocket(...) or WebSocketStream
against untrusted endpoints.
Workaround: none — upgrade is required.
TLS certificate validation bypass in SOCKS5 ProxyAgent — CVE-2026-9697
The ProxyAgent silently discarded the requestTls option when configured with
a SOCKS5 proxy. TLS connections through the SOCKS5 tunnel ignored user-configured
parameters such as ca, cert, key, rejectUnauthorized, and servername,
falling back to the default Mozilla CA bundle. Applications relying on
certificate pinning to an internal CA were exposed to man-in-the-middle attacks.
Affected:ProxyAgent / Socks5ProxyAgent over SOCKS5 that rely on requestTls.
Workaround: route traffic through an HTTP-proxy ProxyAgent, where requestTls functions correctly.
Cross-origin request routing via SOCKS5 proxy pool reuse — CVE-2026-6734
Socks5ProxyAgent reused a single connection pool across different origins
without verifying the pool's origin matched the requested origin. This could
route credentials and request data to unintended destinations, cause responses
from the wrong origin to be trusted, and enable HTTPS→HTTP downgrade.
Affected: applications using Socks5ProxyAgent across multiple origins
(introduced in 7.23.0 via #4385).
Workaround: use a separate agent instance per origin.
Moderate severity
Cross-user information disclosure via shared cache whitespace bypass — CVE-2026-9678
The cache interceptor mishandled responses with whitespace-padded Cache-Control directives such as private=" authorization". In shared-cache
mode this could cause authenticated data to be cached and served to other users.
Affected: apps using the cache interceptor in shared mode that forward Authorization upstream and receive non-canonical qualified directives.
Workaround: disable shared-cache mode for authenticated traffic, avoid
caching authenticated responses, or add Vary: Authorization upstream.
HTTP header injection via Set-Cookie percent-decoding — CVE-2026-9679
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. Introduced in 7.0.0 via #3789.
Workaround: sanitize values before forwarding — strip or reject CR, LF,
NUL, ;, and =.
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:ea8930cffix: guard idle socket validation to skip fresh sockets, hardened by 8e4046e4keep idle validation on native timers (#5402) and 0fa80869keep idle validation on global timers (#5409)
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
v7.28.0 is a security-only release — every change in it is one of the fixes
above, backported to the v7.x maintenance line on purpose from the v8
development line:
#5423 — backport of the WebSocket maxPayloadSize fragment-count / cumulative-size limits (CVE-2026-12151).
#5402 & #5409 — backport of the idle-validation hardening (native + global timers) for the queue-poisoning fix (CVE-2026-6733).
Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.
This PR includes no changesets
When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types
renovateBot
changed the title
chore(deps): update dependency undici to v7.28.0 [security]
chore(deps): update dependency undici to v7.29.0 [security]
Aug 4, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
7.27.1→7.29.0undici vulnerable to cross-user information disclosure via shared cache whitespace bypass
CVE-2026-9678 / GHSA-pr7r-676h-xcf6
More information
Details
Impact
Undici's cache interceptor incorrectly classifies some responses as cacheable when the upstream
Cache-Controlheader uses whitespace-padded qualifiedprivateorno-cachefield names such asprivate=" authorization"orno-cache="\tauthorization". The parser preserves the surrounding whitespace, so later comparisons against the literalauthorizationfield name fail and the response is stored.In shared-cache mode, this allows a response containing one user's authenticated data to be served from cache to a subsequent caller, including an unauthenticated caller, when both requests resolve to the same cache key.
Affected applications are those that explicitly enable the cache interceptor (
interceptors.cache()) in shared mode, forwardAuthorizationheaders upstream, and receive cacheable responses with non-canonical qualifiedprivateorno-cachedirectives.Patches
Upgrade to undici v7.28.0 or v8.5.0.
Workarounds
If upgrade is not immediately possible, disable shared-cache mode for traffic that includes
Authorizationheaders, avoid caching responses to authenticated requests, or addVary: Authorizationupstream.Severity
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
undici vulnerable to TLS certificate validation bypass via dropped requestTls in SOCKS5 ProxyAgent
CVE-2026-9697 / GHSA-vmh5-mc38-953g
More information
Details
Impact
undici's
ProxyAgentsilently drops therequestTlsoption when configured with a SOCKS5 proxy URI (socks5://orsocks://). The target HTTPS connection through the SOCKS5 tunnel falls back to Node's default trust store, ignoring user-configuredca,cert,key,rejectUnauthorized, andservernamesettings.Applications that pin to an internal or corporate CA via
requestTls.cawill, when their proxy URI is SOCKS5, get the default Mozilla CA bundle as the trust anchor instead. Any cert signed by any publicly-trusted CA for the target hostname is accepted, breaking the intended pin and enabling MITM read and tamper of the HTTPS exchange.Affected applications are those that use undici's
ProxyAgent(orSocks5ProxyAgentdirectly) with SOCKS5 AND rely onrequestTlsfor TLS scope restriction. The bug was introduced in undici 7.23.0 when SOCKS5 support was added.Patches
Upgrade to undici v7.28.0 or v8.5.0.
Workarounds
No workaround is available within the SOCKS5 path. If a SOCKS5 proxy with TLS scope restriction is required and an upgrade is not yet possible, route the traffic through an HTTP-proxy
ProxyAgentinstead, whererequestTlsis honored correctly.Severity
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:NReferences
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: 0on the Client or Pool.Severity
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
undici vulnerable to cross-origin request routing via SOCKS5 proxy pool reuse
CVE-2026-6734 / GHSA-hm92-r4w5-c3mj
More information
Details
Impact
When using
Socks5ProxyAgent, undici reuses a single connection pool across different origins without verifying that the pool's origin matches the requested origin. All requests are dispatched through the pool connected to the first origin, regardless of the intended destination.This causes cross-origin request routing: credentials and request data intended for origin B are sent to origin A, responses from the wrong origin are trusted, and HTTPS requests may be silently downgraded to HTTP.
Impacted users are applications that use
Socks5ProxyAgent(directly or viasetGlobalDispatcher) and make requests to more than one origin.This was introduced in undici 7.23.0 via #4385 and affects all versions through 8.1.0.
Patches
Upgrade to undici v7.28.0 or v8.2.0
Workarounds
Use a separate
Socks5ProxyAgentinstance per origin, or avoid usingSocks5ProxyAgentwith multiple origins.Severity
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:HReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
undici WebSocket client vulnerable to denial of service via fragment count bypass
CVE-2026-12151 / GHSA-vxpw-j846-p89q
More information
Details
Impact
The undici WebSocket client enforces
maxPayloadSizeon the cumulative byte count of fragments in a message but does not enforce a limit on the number of fragments. A malicious WebSocket server can stream many small or empty continuation frames that each pass per-frame and cumulative-size validation, collectively causing unbounded memory growth in the client process. The result is memory exhaustion and a denial of service.Affected applications are those using the undici WebSocket client (
new WebSocket(...)) or theWebSocketStreamAPI that can be induced to connect to an attacker-controlled or compromised WebSocket endpoint.All releases starting at undici 6.17.0 are affected.
Patches
Upgrade to undici v6.27.0, v7.28.0 or v8.5.0.
Workarounds
No workaround is available. The fix must be applied through an upgrade.
Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.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
parseSetCookiepercent-decodes cookie values viaqsUnescape, turning encoded sequences like%0D%0A,%00,%3B, and%3Dinto their literal byte equivalents. RFC 6265 §5.4 does not specify any decoding and browsers do not decode either.Applications that parse a
Set-Cookieheader 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 arbitrarySet-Cookie,Location, orCache-Controlheaders 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/getSetCookiesdirectly into response headers; sanitize the value first to strip or reject CR, LF, NUL,;, and=bytes.Severity
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:NReferences
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-Cookieheader, it accepts anySameSiteattribute value that containsStrict,Lax, orNoneas 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=NoneOfYourBusinessis parsed asNone, the most permissive setting.SameSite=StrictLaxis parsed asLax, a downgrade fromStrict.Affected applications are those that consume
Set-Cookieheaders from server responses (for example via undici'sfetchor proxy code paths) and then forward or rely on the parsedsameSiteattribute. 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-Cookieheader, validate that the resultingsameSiteattribute is one of'Strict','Lax', or'None'(exact, case-insensitive) before forwarding or relying on it.Severity
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
undici vulnerable to cross-user information disclosure and parse-time crash via degenerate private cache directives
CVE-2026-13697 / GHSA-4cwx-7wf7-3272
More information
Details
Summary
Two issues in undici's cache interceptor, both fixed by the same patch on
lib/util/cache.js:Cache-Control: privatedirectives such asprivate=""orprivate=","can be incorrectly stored in the default shared cache, then served to a later caller with the same cache key.privatedirectives in the same header (such aspublic, max-age=60, private, private="hdr") cause an uncaughtTypeErrorin the cache-control parser, terminating the request.Impact
Shared-cache disclosure
Applications using
interceptors.cache()in shared mode may cache a user-specific response and serve it to a later caller with the same cache key. This can disclose private response bodies and headers, includingSet-Cookie.Required conditions:
Cache-Control: public, max-age=300, private="";Varyheader.Parse-time crash
Applications using
interceptors.cache()against an upstream that returns aCache-Controlheader combining unqualifiedprivatewith qualifiedprivate="..."see an uncaughtTypeError: output.private.concat is not a functionduring response handling. The request rejects; depending on the consumer's error handling, the process may exit.Details
private=""is parsed as{ private: [''] }. The shared-cache guard only rejectsprivate === true, so the response can be stored. When served from cache, the previous user's body and headers may be returned to a different user.For the crash variant, an unqualified
privatedirective setsoutput.private = true, then a subsequent qualifiedprivate="hdr"directive attemptsoutput.private.concat(['hdr']), which throws because boolean has noconcatmethod.The patch routes the qualified-directive path through a shared helper that normalizes empty-after-trim arrays to
trueand preserves existingtruevalues, closing both vectors.Patches
Upgrade to
undici7.29.0 or 8.9.0. Both releases fix the qualifiedprivatedirective handling that caused the shared-cache storage and the parser crash.Workarounds
Until patched, avoid shared
interceptors.cache()for user-specific responses, usetype: 'private', or disable caching for affected origins.Credit
Disclosure variant reported by @h0rk1p via HackerOne report #3817497.
Severity
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:HReferences
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 theContent-Lengthheader exposed to the application after a retry or resume of a partial response. Applications that useinterceptors.retry()and forward upstream response headers and bodies downstream, for example proxy or gateway applications, may emit an invalid HTTP response with a staleContent-Lengthheader. 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 Contentresponse such as:and then send only 99 bytes before closing the socket.
interceptors.retry()can then retry withRange: bytes=99-99, receive the final byte, and deliver a 100-byte body to the application while the response headers still containContent-Length: 300from 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 recalculateContent-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
interceptors.retry()for untrusted upstreams.Content-Lengthbefore forwarding a response body assembled or transformed by Undici.Severity
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:NReferences
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
setCookiefunction has two attribute injection paths.validateCookieDomaindoes not reject semicolons (validateCookiePathalready does at 0x3B), so adomainvalue likeexample.com; SameSite=Nonelands verbatim asDomain=example.com; SameSite=None. Theunparsedarray's loop only checks each entry contains=and does not sanitize values, so an entry likeX-Custom=val; HttpOnlylands unchanged, injectingHttpOnlywithout the caller settingcookie.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,
SecureorHttpOnlyforced or stripped, or the intended SameSite tier overridden.Patches
Patched in undici v6.28.0, v7.29.0, and v8.9.0.
Workarounds
domainvalues against the RFC 1034 letter-digit-hyphen set before passing tosetCookie.unparsedfield.Severity
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
undici vulnerable to cross-user information disclosure via whitespace around equals in Cache-Control directives
CVE-2026-14643 / GHSA-jr45-8vmc-qm54
More information
Details
Impact
Undici's cache interceptor mishandles optional whitespace (OWS) placed around the
=of a qualifiedno-cacheorprivateCache-Control directive, such asno-cache ="authorization"(OWS before=) orno-cache= "authorization"(OWS after=). The parser either drops the directive entirely or stores a field name with literal quote characters, so the downstream cache decisions do not recognize the qualification and the response is stored.In shared-cache mode, this allows a response containing one user's authenticated data to be served from cache to a subsequent caller, including an unauthenticated caller, when both requests resolve to the same cache key. The impact class is identical to CVE-2026-9678 (GHSA-pr7r-676h-xcf6); this advisory covers the whitespace-around-
=bypass that the earlier fix did not normalize.Affected applications are those that explicitly enable the cache interceptor (
interceptors.cache()) in shared mode, forwardAuthorizationheaders upstream, and receive cacheable responses with qualifiedprivateorno-cachedirectives whose field-name list is padded with OWS around the=.Patches
Upgrade to undici v7.29.0 or v8.9.0.
Workarounds
If upgrade is not immediately possible, disable shared-cache mode for traffic that includes
Authorizationheaders, avoid caching responses to authenticated requests, or addVary: Authorizationupstream.Severity
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:NReferences
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(), ordispatch()) with a.typederived 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.jspushesbody.typedirectly into the outgoing headers with no validation, while every other header path in undici goes throughisValidHeaderValue():The bug requires a hand-rolled duck-typed blob object or a Blob subclass with a controlled
.type. NativeBlobis safe because its constructor strips CRLF from.type.fetch()is unaffected because it validates via theHeadersclass. Ecosystem consumers that build duck-typed blob shapes from user input includeform-data-encoder,formdata-polyfill, andformdata-node.Same defect class as
CVE-2022-35948(explicitcontent-typesink, fixed in undici 5.8.2) andCVE-2026-1527(upgradeoption sink, fixed in 6.24.0 / 7.24.0), both closed by addingisValidHeaderValue()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
content-typeheader on the request options (skips the vulnerable branch).Blob(orfetch-blob) instead of a hand-rolled duck-typed object..type.fetch()instead of the non-fetchAPIs.Severity
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Release Notes
nodejs/undici (undici)
v7.29.0Compare Source
What's Changed
Full Changelog: nodejs/undici@v7.28.0...v7.29.0
v7.28.0Compare Source
This release line addresses 7 security advisories, all shipped in v7.28.0.
The v7 line is not affected by GHSA-38rv-x7px-6hhq (CVE-2026-9675), which is
an 8.x-only regression.
Summary
8cb10f9804201f893805b8f885a24055d0574cc4d0574cc4ea8930cfHigh severity
WebSocket DoS via fragment count bypass — CVE-2026-12151
GHSA-vxpw-j846-p89q · CWE-400, CWE-770
Fix:
8cb10f98websocket: limit the number of fragments in a message (part of backporta027a4a0Backport WebSocket maxPayloadSize fixes to v7.x, #5423)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.
new WebSocket(...)orWebSocketStreamagainst untrusted endpoints.
TLS certificate validation bypass in SOCKS5 ProxyAgent — CVE-2026-9697
GHSA-vmh5-mc38-953g · CWE-295
Fix:
04201f89fix: honor requestTls when proxy is SOCKS5 (#5417)The
ProxyAgentsilently discarded therequestTlsoption when configured witha SOCKS5 proxy. TLS connections through the SOCKS5 tunnel ignored user-configured
parameters such as
ca,cert,key,rejectUnauthorized, andservername,falling back to the default Mozilla CA bundle. Applications relying on
certificate pinning to an internal CA were exposed to man-in-the-middle attacks.
ProxyAgent/Socks5ProxyAgentover SOCKS5 that rely onrequestTls.ProxyAgent, whererequestTlsfunctions correctly.Cross-origin request routing via SOCKS5 proxy pool reuse — CVE-2026-6734
GHSA-hm92-r4w5-c3mj · CWE-346
Fix:
3805b8f8fix(socks5-proxy-agent): use per-origin pools to prevent cross-origin routing (#5041)Socks5ProxyAgentreused a single connection pool across different originswithout verifying the pool's origin matched the requested origin. This could
route credentials and request data to unintended destinations, cause responses
from the wrong origin to be trusted, and enable HTTPS→HTTP downgrade.
Socks5ProxyAgentacross multiple origins(introduced in 7.23.0 via #4385).
Moderate severity
Cross-user information disclosure via shared cache whitespace bypass — CVE-2026-9678
GHSA-pr7r-676h-xcf6 · CWE-524
Fix:
85a24055fix(cache): trim qualified field namesThe cache interceptor mishandled responses with whitespace-padded
Cache-Controldirectives such asprivate=" authorization". In shared-cachemode this could cause authenticated data to be cached and served to other users.
Authorizationupstream and receive non-canonical qualified directives.caching authenticated responses, or add
Vary: Authorizationupstream.HTTP header injection via Set-Cookie percent-decoding — CVE-2026-9679
GHSA-p88m-4jfj-68fv · CWE-93
Fix:
d0574cc4fix(cookies): preserve values and parse SameSite strictlyparseSetCookieapplied percent-decoding to cookie values, turning encodedsequences like
%0D%0Aand%00into literal bytes, contrary to RFC 6265 §5.4and browser behavior. Applications forwarding parsed Set-Cookie values into
response headers were exposed to header injection, enabling session fixation,
open redirects, and cache poisoning. Introduced in 7.0.0 via
#3789.
NUL,
;, and=.Low severity
Set-Cookie SameSite attribute downgrade — CVE-2026-11525
GHSA-g8m3-5g58-fq7m · CWE-183
Fix:
d0574cc4fix(cookies): preserve values and parse SameSite strictlyThe cookie parser accepted
SameSitevalues containingStrict,Lax, orNoneas substrings rather than requiring exact matches per RFC 6265. Valueslike
SameSite=NoneOfYourBusinessparsed asNone, andSameSite=StrictLaxparsed as
Lax, silently weakening cookie security policies for apps thatforward parsed attributes.
HTTP response queue poisoning via keep-alive socket reuse — CVE-2026-6733
GHSA-35p6-xmwp-9g52 · CWE-367 (TOCTOU race condition)
Fix:
ea8930cffix: guard idle socket validation to skip fresh sockets, hardened by8e4046e4keep idle validation on native timers (#5402) and0fa80869keep idle validation on global timers (#5409)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.
keep-alive reuse.
keepAliveTimeout: 0on theClient or Pool.
Release contents & deliberate backports
v7.28.0 is a security-only release — every change in it is one of the fixes
above, backported to the v7.x maintenance line on purpose from the v8
development line:
#5423— backport of the WebSocketmaxPayloadSizefragment-count / cumulative-size limits (CVE-2026-12151).#5402ᔡ— backport of the idle-validation hardening (native + global timers) for the queue-poisoning fix (CVE-2026-6733).#5417—requestTlsover SOCKS5 fix (CVE-2026-9697).The cookie (
d0574cc4),cache (
85a24055) andqueue-poisoning core (
ea8930cf)fixes were applied directly to the v7.x branch. Full changelog:
v7.27.2...v7.28.0.Credits
Per-advisory credits (as recorded in each GHSA):
v7.27.2Compare Source
What's Changed
Full Changelog: nodejs/undici@v7.27.1...v7.27.2
Configuration
📅 Schedule: (UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ 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.
This PR was generated by Mend Renovate. View the repository job log.