Source: node-undici Version: 7.24.6+dfsg+~cs3.2.0-3 Severity: important Tags: security upstream X-Debbugs-Cc: [email protected], Debian Security Team <[email protected]>
Hi, The following vulnerabilities were published for node-undici. CVE-2026-6733[0]: | 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.26.0, v7.28.0 or v8.5.0. Workarounds: Disable | keep-alive connection reuse by setting keepAliveTimeout: 0 on the | Client or Pool. CVE-2026-6734[1]: | 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 via | setGlobalDispatcher) and make requests to more than one origin. | This was introduced in undici 7.23.0 via PR #4385 and affects all | versions through 8.1.0. Patches: Upgrade to undici v7.26.0 or | v8.2.0. Workarounds: Use a separate Socks5ProxyAgent instance per | origin, or avoid using Socks5ProxyAgent with multiple origins. CVE-2026-9678[2]: | Impact: 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. CVE-2026-9679[3]: | 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 PR #3789. Patches: Upgrade to undici v6.26.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. CVE-2026-9697[4]: | Impact: 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. CVE-2026-11525[5]: | 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. For example, SameSite=NoneOfYourBusiness is parsed | as None (the most permissive setting), and 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.26.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. CVE-2026-12151[6]: | Impact: 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 >= 6.26.0, >= | 7.28.0, or >= 8.5.0. Workarounds: No workaround is available. The | fix must be applied through an upgrade. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2026-6733 https://www.cve.org/CVERecord?id=CVE-2026-6733 [1] https://security-tracker.debian.org/tracker/CVE-2026-6734 https://www.cve.org/CVERecord?id=CVE-2026-6734 [2] https://security-tracker.debian.org/tracker/CVE-2026-9678 https://www.cve.org/CVERecord?id=CVE-2026-9678 [3] https://security-tracker.debian.org/tracker/CVE-2026-9679 https://www.cve.org/CVERecord?id=CVE-2026-9679 [4] https://security-tracker.debian.org/tracker/CVE-2026-9697 https://www.cve.org/CVERecord?id=CVE-2026-9697 [5] https://security-tracker.debian.org/tracker/CVE-2026-11525 https://www.cve.org/CVERecord?id=CVE-2026-11525 [6] https://security-tracker.debian.org/tracker/CVE-2026-12151 https://www.cve.org/CVERecord?id=CVE-2026-12151 Regards, Salvatore -- Pkg-javascript-devel mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
