Skip to content

chore(deps): update dependency jsdom>undici to v8 [security] - #1597

Open
renovate[bot] wants to merge 1 commit into
stagefrom
renovate/npm-jsdom-undici-vulnerability
Open

chore(deps): update dependency jsdom>undici to v8 [security]#1597
renovate[bot] wants to merge 1 commit into
stagefrom
renovate/npm-jsdom-undici-vulnerability

Conversation

@renovate

@renovate renovate Bot commented Aug 4, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package Change Age Confidence
jsdom>undici (source) ^7.28.0 → ^8.9.0 age confidence

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:

  1. 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.
  2. 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.

Severity

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

References

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

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

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 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.

Severity

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

References

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

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

Release Notes

nodejs/undici (jsdom>undici)

v8.9.0

Compare Source

What's Changed

New Contributors

Full Changelog: nodejs/undici@v8.8.0...v8.9.0

v8.8.0

Compare Source

What's Changed

New Contributors

Full Changelog: nodejs/undici@v8.7.0...v8.8.0

v8.7.0

Compare Source

What's Changed
New Contributors

Full Changelog: nodejs/undici@v8.6.0...v8.7.0

v8.6.0

Compare Source

v8.5.0

Compare Source

⚠️ Security Release

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.

Action required: Upgrade to undici 8.5.0 or later.

npm install undici@^8.5.0

Summary

Advisory CVE Severity (CVSS) Fixed in Fix commit
GHSA-vxpw-j846-p89q CVE-2026-12151 High (7.5) 8.5.0 32dbf0b3
GHSA-38rv-x7px-6hhq CVE-2026-9675 High (7.5) 8.5.0 b4c287b3
GHSA-vmh5-mc38-953g CVE-2026-9697 High (7.4) 8.5.0 42d49559
GHSA-hm92-r4w5-c3mj CVE-2026-6734 High (7.5) 8.2.0 a516f870
GHSA-pr7r-676h-xcf6 CVE-2026-9678 Moderate (5.9) 8.5.0 cb105d7c
GHSA-p88m-4jfj-68fv CVE-2026-9679 Moderate (5.9) 8.5.0 5655ea43
GHSA-g8m3-5g58-fq7m CVE-2026-11525 Low (3.7) 8.5.0 5655ea43
GHSA-35p6-xmwp-9g52 CVE-2026-6733 Low (3.7) 8.5.0 6ea54ef8

High severity

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

GHSA-vxpw-j846-p89q · CWE-400, CWE-770
Fix: 32dbf0b3 websocket: limit the number of fragments in a message (also c5ed7875 handle 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.

  • Affected: applications using new WebSocket(...) or WebSocketStream
    against untrusted endpoints.
  • Workaround: none — upgrade is required.
WebSocket DoS via cumulative fragment bypass — CVE-2026-9675

GHSA-38rv-x7px-6hhq · CWE-400, CWE-770
Fix: b4c287b3 fix(websocket): enforce max payload size across fragments

Undici 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).

  • Workaround: none — upgrade is required.
TLS certificate validation bypass in SOCKS5 ProxyAgent — CVE-2026-9697

GHSA-vmh5-mc38-953g · CWE-295
Fix: 42d49559 fix: honor requestTls when proxy is SOCKS5

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

GHSA-hm92-r4w5-c3mj · CWE-346 · Fixed in 8.2.0
Fix: a516f870 fix(socks5-proxy-agent): use per-origin pools to prevent cross-origin routing (#​5041)

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 via #​4385).
  • Workaround: use a separate agent instance per origin.

Moderate severity

Cross-user information disclosure via shared cache whitespace bypass — CVE-2026-9678

GHSA-pr7r-676h-xcf6 · CWE-524
Fix: cb105d7c fix(cache): trim qualified field names

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

GHSA-p88m-4jfj-68fv · CWE-93
Fix: 5655ea43 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. Introduced in 7.0.0 via
#​3789.

  • 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: 5655ea43 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: 6ea54ef8 fix: guard idle socket validation to skip fresh sockets, hardened by c9fbe9d2 keep idle validation on native timers (#​5397) and ac5394b8 keep 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.

  • Requirements: attacker-controlled/compromised upstream and active
    keep-alive reuse.
  • Workaround: disable keep-alive reuse with keepAliveTimeout: 0 on the
    Client 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.)

  • HTTP/2: #5408 don't rewind kPendingIdx past in-flight requests · #5391 allow h2 POST request multiplexing · #5406 reap idle HTTP/2 sessions · #5410 preserve h2 queue on out-of-order completion
  • Features: #5416 add bodyMixin.textStream() · #5418 align EventSource with spec
  • Docs / CI / tests: #5413 document request header validation · #5383 absorb h2 stream timeout resets (test) · #5420 remove stale repro + lint · #5426 extend Windows CI timeout · #5427 detect available python in WPT runner

Full changelog: v8.4.1...v8.5.0.

Credits

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

v8.4.1

Compare Source

What's Changed

New Contributors

Full Changelog: nodejs/undici@v8.4.0...v8.4.1

v8.4.0

Compare Source

What's Changed

New Contributors

Full Changelog: nodejs/undici@v8.3.0...v8.4.0

v8.3.0

Compare Source

What's Changed

✂ Note

PR body was truncated to here.

Configuration

📅 Schedule: (in timezone America/New_York)

  • Branch creation
    • At any time (no schedule defined)
  • 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.

@renovate
renovate Bot requested a review from a team as a code owner August 4, 2026 01:18
@github-actions

github-actions Bot commented Aug 4, 2026

Copy link
Copy Markdown

Coverage Report

Status Category Percentage Covered / Total
🔵 Lines 81.93% 4360 / 5321
🔵 Statements 81.22% 4723 / 5815
🔵 Functions 79.04% 913 / 1155
🔵 Branches 75% 3129 / 4172
File CoverageNo changed files found.
Generated in workflow #1661 for commit 785852f by the Vitest Coverage Report Action

@DavidCockerill DavidCockerill mentioned this pull request Aug 4, 2026
Open
1 task
DavidCockerill
DavidCockerill requested changes Aug 4, 2026
View reviewed changes

@DavidCockerill DavidCockerill left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Real advisory, wrong remedy — requesting changes on the fix, not the intent.

The advisory checks out: CVE-2026-13697 / GHSA-4cwx-7wf7-3272, High, CVSS 7.4. But worth being precise about exposure before it drives urgency: undici is here only as a transitive dep of jsdom, which is a devDependency test environment. The vulnerable cache interceptor is never used, and nothing reaches a browser or a server. This is a CI-only exposure, not a production one.

The problem is the change itself: the override this edits exists specifically to block this bump, and CI shows why — 64 test files fail because jsdom 29 requires an undici internal that 8.x removed. Thread has two working alternatives; the cleaner is to land #1596 (jsdom v30) and then delete this override entirely.

— Reviewed by DAIvid (Claude Opus 5)

Comment thread pnpm-workspace.yaml
# undici 7.x until a jsdom release supports undici 8, otherwise its tests crash
# with "Cannot find module 'undici/lib/handler/wrap-handler.js'".
'jsdom>undici': '^7.28.0'
'jsdom>undici': '^8.9.0'

@DavidCockerill DavidCockerill Aug 4, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This override exists to prevent exactly this bump — the comment three lines up predicts the failure, and CI reproduces it: 64 test files die with Cannot find module 'undici/lib/handler/wrap-handler.js'. jsdom 29.1.1's jsdom-dispatcher.js:8 still requires that internal path, and undici 8.7/8.9 don't ship it.

Two better remedies:

  1. Land chore(deps): update dependency jsdom to v30 #1596 first (jsdom v30 depends on undici: ^8.9.0) and delete this override outright — the general 'undici@>=7.0.0': '^8.0.0' then covers jsdom. This is the one I'd take.
  2. If chore(deps): update dependency jsdom to v30 #1596 stalls, set '^7.29.0' — the patched 7.x release for GHSA-4cwx-7wf7-3272, which also satisfies jsdom 29's ^7.25.0. One character, advisory cleared, tests green.

Exposure is CI-only either way (see the summary).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@DavidCockerill DavidCockerill DavidCockerill requested changes

Requested changes must be addressed to merge this pull request.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@DavidCockerill