fix(deps): update dependency undici to v7.30.1 [security] by renovate[bot] · Pull Request #6695 · heygen-com/hyperframes

renovate · 2026-10-28T20:36:49Z

Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package	Change	Age	Confidence
undici (source)	`7.25.0` → `7.30.1`

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

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 TLS certificate validation bypass via dropped requestTls in SOCKS5 ProxyAgent

CVE-2026-9697 / GHSA-vmh5-mc38-953g

More information

Details

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.

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:H/A:N

References

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

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

Severity

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

References

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

Severity

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

References

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

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

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:

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.

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

undici vulnerable to Denial of Service via WebSocketStream unclean close

CVE-2026-85014 / GHSA-rx4f-c7p8-82vq

More information

Details

Impact

undici's WebSocketStream crashes the client process when a WebSocket connection is closed abruptly without a close handshake. On such an unclean close, the internal socket-close handler calls abort() on the writable stream even when the application holds a writer lock. Per the WHATWG Streams standard, aborting a locked stream returns a promise that rejects with a TypeError, and the handler discards that promise. The unobserved rejection surfaces as an unhandledRejection and, under Node.js's default behavior, terminates the process.

A malicious or compromised WebSocket server can crash a client with a single connection teardown (a TCP reset, a proxy teardown, or a protocol-violating frame). Affected applications are those using the WebSocketStream API and writing through a writer, which is the standard way to write.

All releases from undici 7.0.0 are affected. WebSocketStream was introduced in 7.0.0.

Patches

Upgrade to undici v7.29.1 or v8.10.2.

Workarounds

No workaround is available.

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:N/A:H

References

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

undici vulnerable to caching and replay of unsafe HTTP method responses

CVE-2026-85008 / GHSA-8436-99hf-9mmv

More information

Details

Impact

undici's interceptors.cache() documents that it caches only safe HTTP methods. However, its internal skip-list is built by subtracting the configured methods from the safe-methods set, so an unsafe method (POST, PUT, PATCH, DELETE) never lands in the skip-list and is looked up against the cache store. Combined with the storage gate (canCacheResponse) having no method check, a heuristically-cacheable response (for example a 404) with an explicit Cache-Control: max-age=... to an unsafe method is stored and replayed on a subsequent identical request. The application's state-changing request never reaches the origin, and undici serves a fabricated response from the cache instead. This occurs with the default configuration (methods: ['GET']), which the public API does not allow widening to unsafe methods, so no application misuse is required; an untrusted origin can trigger it purely through its own response headers.

Patches

Upgrade to 7.29.1 or 8.10.2. The cache interceptor no longer reads from or writes to the cache for unsafe HTTP methods, while still invalidating existing cache entries on successful unsafe requests.

Workarounds

None.

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

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

undici vulnerable to TLS certificate validation bypass via dropped connect options in BalancedPool

CVE-2026-84961 / GHSA-w293-vg96-wgc3

More information

Details

Impact

undici's BalancedPool passes its constructor options through a JSON-based deep clone (JSON.parse(JSON.stringify(...))) before forwarding them to each per-upstream Pool. JSON cannot represent functions, so a caller-supplied connect or tls option containing a checkServerIdentity callback (or a custom connector function) is silently dropped before it reaches the TLS layer. As a result, a TLS peer whose certificate a custom checkServerIdentity was written to reject, but which passes Node's default hostname and chain checks, is silently accepted when the request is made through BalancedPool. Client, Pool, Agent, and RoundRobinPool destructure connect/tls before the clone and are not affected. Only applications that use BalancedPool with a function-valued connect/tls option (such as a custom checkServerIdentity or connector) are affected.

Patches

Upgrade to 7.29.1 or 8.10.2. BalancedPool now preserves the connect and tls options outside the JSON clone, so custom TLS verification callbacks are forwarded to each upstream unchanged.

Workarounds

Use Client, Pool, or Agent instead of BalancedPool for connections that rely on a custom checkServerIdentity or connector, until upgraded.

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:H/A:N

References

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

undici vulnerable to response truncation via oversized chunked responses in the dump interceptor

CVE-2026-84947 / GHSA-2gqq-gqf2-x968

More information

Details

Impact

undici's interceptors.dump() reads and discards response bodies up to a configurable maxSize. When a response declares a Content-Length that exceeds maxSize, the request is aborted cleanly. When a response is sent chunked (no Content-Length) and its body exceeds maxSize, it is not aborted: the interceptor ends the response early once the accumulated size reaches maxSize, and continued delivery from the parser triggers an internal assertion that is caught and turned into a request abort and connection tear-down. The application observes a misleading 200 with an empty or truncated body while the connection is disconnected. Any application using the dump interceptor against untrusted or misbehaving upstreams is affected.

Patches

Upgrade to 7.29.1 or 8.10.2. The dump interceptor now enforces maxSize on both the declared and the received body size, aborting the request with a RequestAbortedError instead of returning a truncated response.

Workarounds

None. Avoid using interceptors.dump() with untrusted upstreams until upgraded.

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

[!IMPORTANT]
✂ PR body was truncated to here.

github-actions · 2026-10-28T20:57:14Z

Edit accuracy: accurate 267 (base branch 267), smooth 124 of those

The gate passes.
Smoothness is reported in the artifact, not gated. A case fails only if it fails 2 of 3 runs.

Quarantined, measured but not gated (8)

seqplainkeys-none-center-r0-nested-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): pass, passes
seqplainkeys-none-center-r0-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): fail / pass / pass, passes
seqplainkeys-none-center-r30-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run
seqplainkeys-none-pct-r0-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): pass, passes
seqplainkeys-none-pct-r30-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run
seqplainkeys-none-px-r0-nested-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): pass, passes
seqplainkeys-none-px-r30-nested-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run
seqplainkeys-none-px-r30-root-z100 (fixed by studio: undo/redo on a keyframed plain element sometimes leaves the box 230-400px off (edit-accuracy seqplainkeys-none-*) #6989): not run

Unstable (1)

seqplainkeys-none-pct-r0-nested-z100: tracking 0.05, pressJump 0, drop 0, reload 0, render 0.02, renderKey -, undo false, teleport true / tracking 0.05, pressJump 0, drop 0, reload 0, render 0.02, renderKey -, undo true, teleport true / tracking 0.05, pressJump 0, drop 0, reload 0, render 0.02, renderKey -, undo true, teleport true

…view to heygen-com#7265 Adopt heygen-com#7284 (Studio Storyboard tab and `doc: "storyboard"` Desktop handoff, adapted to the fork's desktopApp without heygen-com#6897) and heygen-com#7324 (drawElement gate: webgl_unavailable / beginframe_no_self_verify). PR axis heygen-com#7260-heygen-com#7265 carries earlier verdicts; re-pin heygen-com#6695 and heygen-com#6816, resolve heygen-com#7150 as superseded by heygen-com#5746. Watermarks: commit 18fc75d, PR heygen-com#7265, issue heygen-com#7223, monitored 99. Co-authored-by: WaterrrForever <[email protected]> Co-authored-by: Vance Ingalls <[email protected]> Co-Authored-By: Claude Sonnet 5.5 <[email protected]> Co-Authored-By: Claude Opus 5.5 <[email protected]>

heygengenesis

Verdict: APPROVE (first pass, maintainer approval still needed) · 0 blocker · 0 important · 1 nit

Both undici pins (packages/cli, packages/engine) move to 7.30.1 and bun.lock keeps a single [email protected] entry, which jsdom's ^7.25.0 also resolves to. 7.30.1 is the first patched 7.x release for the Oct 23/27 advisories. The only runtime caller is packages/engine/src/utils/urlDownloader.ts (Agent({ connect: { lookup } }) plus fetch), and that API is unchanged.

nit: this head's CI ran on Nov 6 against a base 259 commits behind main. The merge queue retests the merged result, but asking Renovate to rebase would refresh the PR checks first. The 0.9.10 → 0.9.19 workspace-version churn in bun.lock is harmless. main still records 0.9.10 there.

What I checked

Merged this PR onto current main (d208281): no conflicts. bun install --frozen-lockfile succeeds and resolves [email protected].
NODE_ENV=test vitest run src/utils/urlDownloader* in packages/engine: 94/94 pass on the merged tree. The full engine suite's only failures are ffmpeg and Chrome tests that need binaries this sandbox doesn't have.
No other undici pins. The Lambda runtime locks don't contain undici.

— Genesis (first-pass review requested via Clippy)

jrusso1020

Post-merge advisory review (this PR is already merged into main). Findings would be follow-ups, not gating.

Reviewed at 3b2321c0bcca0edcc40fce84dbaa11af9d8bb6b1.

No blockers found. Independently verified Genesis's compatibility assessment: the only package import is the downloader's Agent/fetch transport; custom DNS lookup, manual redirects with per-hop validation, and abort-driven timeouts remain compatible with the upstream changes. No ProxyAgent call sites need migrating. The upstream Agent change preserves function-valued TLS options while retaining the existing connect-options forwarding (7.30.1 release notes).

Validation on the PR head (not a merged tree): frozen-lockfile install and full build pass; NODE_ENV=test vitest run src/utils/urlDownloader --maxWorkers=2: 94/94 pass, including real-transport private-DNS refusal tests. Parsed lockfile comparison finds undici as the only changed external package; the additional 14 workspace-version refreshes match their package manifests. The patch merges cleanly with current main. Hosted CI passed at this exact head on November 6; those results predate today's main.

Need: yes, security update · Size: ok · Reuse: existing downloader transport · Simpler: already minimal · Structure: fine (checked existing URL downloader; no split)
Risk: low — same-major dependency update with compatible call sites and passing targeted coverage.

Verdict: Ready
Reasoning: Both runtime pins and the resolved package move together, with no introduced correctness or compatibility issue found.

— Rames

renovate Bot added the security label Oct 28, 2026

renovate Bot force-pushed the renovate/npm-undici-vulnerability branch 3 times, most recently from 21ab00f to 8aa9967 Compare November 5, 2026 17:16

fix(deps): update dependency undici to v7.30.1 [security]

3b2321c

renovate Bot force-pushed the renovate/npm-undici-vulnerability branch from 8aa9967 to 3b2321c Compare November 6, 2026 05:00

heygengenesis Bot reviewed Nov 13, 2026

View reviewed changes

miguel-heygen approved these changes Nov 13, 2026

View reviewed changes

miguel-heygen added this pull request to the merge queue Nov 13, 2026

Merged via the queue into main with commit d79e72c Nov 13, 2026
97 checks passed

miguel-heygen deleted the renovate/npm-undici-vulnerability branch November 13, 2026 15:51

jrusso1020 reviewed Nov 13, 2026

View reviewed changes

Navigation Menu

Repository navigation

fix(deps): update dependency undici to v7.30.1 [security] - #6695

fix(deps): update dependency undici to v7.30.1 [security]#6695
miguel-heygen merged 1 commit into
mainfrom
renovate/npm-undici-vulnerability

renovate Bot commented Oct 28, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Oct 28, 2026 •

edited

Loading

Uh oh!

heygengenesis Bot left a comment

Uh oh!

Uh oh!

jrusso1020 left a comment

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

renovate Bot commented Oct 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

undici vulnerable to cross-user information disclosure via shared cache whitespace bypass

Details

Impact

Patches

Workarounds

Severity

References

undici vulnerable to TLS certificate validation bypass via dropped requestTls in SOCKS5 ProxyAgent

Details

Impact

Patches

Workarounds

Severity

References

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

Details

Impact

Patches

Workarounds

Severity

References

undici vulnerable to cross-origin request routing via SOCKS5 proxy pool reuse

Details

Impact

Patches

Workarounds

Severity

References

undici WebSocket client vulnerable to denial of service via fragment count bypass

Details

Impact

Patches

Workarounds

Severity

References

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

Details

Impact

Patches

Workarounds

Severity

References

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

Details

Impact

Patches

Workarounds

Severity

References

undici vulnerable to cross-user information disclosure and parse-time crash via degenerate private cache directives

Details

Summary

Impact

Shared-cache disclosure

Parse-time crash

Details

Patches

Workarounds

Credit

Severity

References

undici vulnerable to downstream response desynchronization via retry interceptor

Details

Impact

Patches

Workarounds

Severity

References

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

Details

Impact

Patches

Workarounds

Severity

References

undici vulnerable to cross-user information disclosure via whitespace around equals in Cache-Control directives

Details

renovate Bot commented Oct 28, 2026 •

edited

Loading

github-actions Bot commented Oct 28, 2026 •

edited

Loading