Update dependency undici to v8.5.0 [SECURITY]#308
Merged
Conversation
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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:
8.4.1→8.5.0undici WebSocket client vulnerable to denial of service via cumulative fragment bypass
CVE-2026-9675 / GHSA-38rv-x7px-6hhq
More information
Details
Impact
The undici WebSocket client enforces
maxPayloadSizeper-frame but does not enforce the cumulative size of fragmented uncompressed messages. A malicious WebSocket server can stream many small fragments that each pass per-frame validation but collectively exceed the configured limit, 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(...)) that can be induced to connect to an attacker-controlled or compromised WebSocket endpoint.This is a regression specific to undici 8.1.0. The 6.25.0 line shipped the equivalent cumulative check from the start and is unaffected. The 7.x line never had the
maxPayloadSizefeature and is also unaffected.Patches
Upgrade to undici >= 8.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 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 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).
Release Notes
nodejs/undici (undici)
v8.5.0Compare Source
This release line addresses 8 security advisories. Most are fixed in
v8.5.0; the SOCKS5 pool-reuse issue was fixed earlier in v8.2.0.
Summary
32dbf0b3b4c287b342d49559a516f870cb105d7c5655ea435655ea436ea54ef8High severity
WebSocket DoS via fragment count bypass — CVE-2026-12151
GHSA-vxpw-j846-p89q · CWE-400, CWE-770
Fix:
32dbf0b3websocket: limit the number of fragments in a message (alsoc5ed7875handle empty fragments and stream limits)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.
WebSocket DoS via cumulative fragment bypass — CVE-2026-9675
GHSA-38rv-x7px-6hhq · CWE-400, CWE-770
Fix:
b4c287b3fix(websocket): enforce max payload size across fragmentsUndici validated the size of individual frames but did not track cumulative size
across a fragmented message. An attacker could send many small fragments that
each pass per-frame validation but collectively exceed the configured limit,
causing memory exhaustion. This is a regression introduced in 8.1.0 (the
6.x and 7.x lines are not affected).
TLS certificate validation bypass in SOCKS5 ProxyAgent — CVE-2026-9697
GHSA-vmh5-mc38-953g · CWE-295
Fix:
42d49559fix: honor requestTls when proxy is SOCKS5The
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 · Fixed in 8.2.0
Fix:
a516f870fix(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 via #4385).
Moderate severity
Cross-user information disclosure via shared cache whitespace bypass — CVE-2026-9678
GHSA-pr7r-676h-xcf6 · CWE-524
Fix:
cb105d7cfix(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:
5655ea43fix(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:
5655ea43fix(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:
6ea54ef8fix: guard idle socket validation to skip fresh sockets, hardened byc9fbe9d2keep idle validation on native timers (#5397) andac5394b8keep idle validation on global timers (#5407)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.
Also in v8.5.0 (non-security)
v8.5.0 shipped the security fixes above alongside the following changes. These
are not security fixes — they are listed for completeness of the release. (The
two queue-poisoning hardening PRs, #5397
and #5407, are covered under
CVE-2026-6733 above and are not repeated here.)
#5408don't rewindkPendingIdxpast in-flight requests ·#5391allow h2 POST request multiplexing ·#5406reap idle HTTP/2 sessions ·#5410preserve h2 queue on out-of-order completion#5416addbodyMixin.textStream()·#5418align EventSource with spec#5413document request header validation ·#5383absorb h2 stream timeout resets (test) ·#5420remove stale repro + lint ·#5426extend Windows CI timeout ·#5427detect available python in WPT runnerFull changelog:
v8.4.1...v8.5.0.Credits
Per-advisory credits (as recorded in each GHSA):
Configuration
📅 Schedule: (UTC)
🚦 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.
This PR was generated by Mend Renovate. View the repository job log.