chore(deps): update dexto to v1.13.1 - #27070

Impact

The undici WebSocket client is vulnerable to a denial-of-service attack due to improper validation of the server_max_window_bits parameter in the permessage-deflate extension. When a WebSocket client connects to a server, it automatically advertises support for permessage-deflate compression. A malicious server can respond with an out-of-range server_max_window_bits value (outside zlib's valid range of 8-15). When the server subsequently sends a compressed frame, the client attempts to create a zlib InflateRaw instance with the invalid windowBits value, causing a synchronous RangeError exception that is not caught, resulting in immediate process termination.

The vulnerability exists because:

1. The isValidClientWindowBits() function only validates that the value contains ASCII digits, not that it falls within the valid range 8-15
2. The createInflateRaw() call is not wrapped in a try-catch block
3. The resulting exception propagates up through the call stack and crashes the Node.js process

Patches

Has the problem been patched? What versions should users upgrade to?

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

Description

The undici WebSocket client is vulnerable to a denial-of-service attack via unbounded memory consumption during permessage-deflate decompression. When a WebSocket connection negotiates the permessage-deflate extension, the client decompresses incoming compressed frames without enforcing any limit on the decompressed data size. A malicious WebSocket server can send a small compressed frame (a "decompression bomb") that expands to an extremely large size in memory, causing the Node.js process to exhaust available memory and crash or become unresponsive.

The vulnerability exists in the PerMessageDeflate.decompress() method, which accumulates all decompressed chunks in memory and concatenates them into a single Buffer without checking whether the total size exceeds a safe threshold.

Impact

• Remote denial of service against any Node.js application using undici's WebSocket client
• A single compressed WebSocket frame of ~6 MB can decompress to ~1 GB or more
• Memory exhaustion occurs in native/external memory, bypassing V8 heap limits
• No application-level mitigation is possible as decompression occurs before message delivery

Patches

Users should upgrade to fixed versions.

Workarounds

No workaround are possible.

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.

Impact

Undici allows duplicate HTTP Content-Length headers when they are provided in an array with case-variant names (e.g., Content-Length and content-length). This produces malformed HTTP/1.1 requests with multiple conflicting Content-Length values on the wire.

Who is impacted:

• Applications using undici.request(), undici.Client, or similar low-level APIs with headers passed as flat arrays
• Applications that accept user-controlled header names without case-normalization

Potential consequences:

• Denial of Service: Strict HTTP parsers (proxies, servers) will reject requests with duplicate Content-Length headers (400 Bad Request)
• HTTP Request Smuggling: In deployments where an intermediary and backend interpret duplicate headers inconsistently (e.g., one uses the first value, the other uses the last), this can enable request smuggling attacks leading to ACL bypass, cache poisoning, or credential hijacking

Patches

Patched in the undici version v7.24.0 and v6.24.0. Users should upgrade to this version or later.

Workarounds

If upgrading is not immediately possible:

1. Validate header names: Ensure no duplicate Content-Length headers (case-insensitive) are present before passing headers to undici
2. Use object format: Pass headers as a plain object ({ 'content-length': '123' }) rather than an array, which naturally deduplicates by key
3. Sanitize user input: If headers originate from user input, normalize header names to lowercase and reject duplicates

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.

Impact

The fetch() API supports chained HTTP encoding algorithms for response content according to RFC 9110 (e.g., Content-Encoding: gzip, br). This is also supported by the undici decompress interceptor.

However, the number of links in the decompression chain is unbounded and the default maxHeaderSize allows a malicious server to insert thousands compression steps leading to high CPU usage and excessive memory allocation.

Patches

Upgrade to 7.18.2 or 6.23.0.

Workarounds

It is possible to apply an undici interceptor and filter long Content-Encoding sequences manually.

References

• https://hackerone.com/reports/3456148
• GHSA-gm62-xv2j-4w53
• https://curl.se/docs/CVE-2022-32206.html

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.

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.

Impact

When an application passes user-controlled input to the upgrade option of client.request(), an attacker can inject CRLF sequences (\r\n) to:

1. Inject arbitrary HTTP headers
2. Terminate the HTTP request prematurely and smuggle raw data to non-HTTP services (Redis, Memcached, Elasticsearch)

The vulnerability exists because undici writes the upgrade value directly to the socket without validating for invalid header characters:

// lib/dispatcher/client-h1.js:1121
if (upgrade) {
  header += `connection: upgrade\r\nupgrade: ${upgrade}\r\n`
}

Patches

Patched in the undici version v7.24.0 and v6.24.0. Users should upgrade to this version or later.

Workarounds

Sanitize the upgrade option string before passing to undici:

function sanitizeUpgrade(value) {
  if (/[\r\n]/.test(value)) {
    throw new Error('Invalid upgrade value')
  }
  return value
}

client.request({
  upgrade: sanitizeUpgrade(userInput)
})

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.

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.

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.

Summary

@<!-- -->opentelemetry/propagator-jaeger decodes incoming HTTP header values with decodeURIComponent() without handling decode errors. A single request carrying a malformed percent-encoded value (for example a bare %) in an uber-trace-id or uberctx-* header throws an uncaught URIError, terminating any Node.js process that uses JaegerPropagator as its active propagator.

Impact

Denial of Service: Any unauthenticated remote attacker who can send an HTTP request to a service that has JaegerPropagator registered as the global propagator (e.g. via OTEL_PROPAGATORS=jaeger or propagation.setGlobalPropagator(new JaegerPropagator())) can terminate the process with a single request. Confidentiality and integrity are not affected.

Am I affected?

This issue affects only a specific, opt-in configuration. If you use OpenTelemetry's default propagators (W3C TraceContext and Baggage), you are not affected.

You are affected only if you have registered JaegerPropagator as the active propagator. Check for:

• @<!-- -->opentelemetry/propagator-jaeger in your dependency tree, and
• OTEL_PROPAGATORS set to jaeger (Jaeger only), or a direct propagation.setGlobalPropagator(new JaegerPropagator()) call in your code.

Note: if JaegerPropagator is combined with other propagators through a CompositePropagator (for example OTEL_PROPAGATORS=jaeger,tracecontext), the process does not terminate - the composite propagator catches the error - but affected requests silently fail to extract context. You should still upgrade.

Patched versions

• @<!-- -->opentelemetry/propagator-jaeger 2.9.0

Remediation

Update @<!-- -->opentelemetry/propagator-jaeger to 2.9.0 or later. The propagator now ignores header values it cannot decode instead of throwing.

Interim mitigation (if you cannot update): Trace-context headers should never be accepted unfiltered from untrusted callers. Until you can upgrade, strip or validate the uber-trace-id and uberctx-* headers on inbound requests at your edge - for example with a reverse proxy, API gateway, or load balancer (nginx, Envoy, etc.) - so that only trusted upstream services can set them.

Details

JaegerPropagator.extract() calls decodeURIComponent() on raw header values at two unguarded call sites: the uber-trace-id trace header and each uberctx-* baggage value. decodeURIComponent() throws URIError: URI malformed on invalid percent-encoding. Because the HTTP instrumentation extracts context before its request-handler error wrapper, and a single configured propagator is not wrapped in a CompositePropagator (which would otherwise catch the error), the exception propagates as an uncaughtException and terminates the process.

Proof of concept

Against a service using JaegerPropagator:

curl -H 'uberctx-user: %' http://target/
# or
curl -H 'uber-trace-id: %' http://target/

The Node.js process exits with URIError: URI malformed and subsequent requests are refused.

Summary

A single malformed HTTP request crashes any Node.js process running the OpenTelemetry JS Prometheus exporter. The metrics endpoint (default 0.0.0.0:9464) has no error handling around URL parsing, so a request with an invalid URI causes an uncaught TypeError that terminates the process.

You are affected by this vulnerability if either of the following apply to your application:

• you directly use @<!-- -->opentelemetry/exporter-prometheus in your code through its built-in server.
• your OTEL_METRICS_EXPORTER environment variable includes prometheus AND
  • you use @<!-- -->opentelemetry/sdk-node
  • you use @<!-- -->opentelemetry/auto-instrumentations-node via --require @<!-- -->opentelemetry/auto-instrumentations-node/register/--import @<!-- -->opentelemetry/auto-instrumentations-node/register

Impact

Denial of service. Any application using the OpenTelemetry Prometheus exporter’s built-in server can be crashed by a single unauthenticated network packet sent to the metrics port. No authentication, special privileges, or prior access is required.

Remediation

Update to the fixed version

Update @<!-- -->opentelemetry/exporter-prometheus and @<!-- -->opentelemetry/sdk-node to version 0.217.0 or later.
Update @<!-- -->opentelemetry/auto-instrumentations-node to version 0.75.0 or later.

This release adds proper error handling around the URL constructor, returning an HTTP 400 response on parse failure rather than allowing the exception to propagate and crash the process.

npm install @<!-- -->opentelemetry/exporter-prometheus@<!-- -->latest

Do Not Expose the Endpoint to Untrusted Users

[!IMPORTANT]
The following mitigations reduce exposure but do not fully remediate the vulnerability. Any client that can reach the metrics endpoint - including your own Prometheus scraper host if compromised - could still trigger the crash. Updating to 0.217.0 is the recommended resolution.

If updating is not immediately feasible, restrict access to the metrics endpoint so that it is not reachable by untrusted or unauthenticated network clients. For example:

• Bind to localhost only by setting the host option to 127.0.0.1 when configuring the PrometheusExporter, so the port is not exposed on public or shared network interfaces

• Use a firewall or network policy to restrict access to port 9464 (or whichever port you have configured) to only trusted Prometheus scrape hosts

• Place the endpoint behind a reverse proxy that filters or validates incoming requests before they reach the exporter

Details

In PrometheusExporter.ts, the _requestHandler calls new URL(request.url, this._baseUrl) without any error handling. Node's HTTP parser accepts absolute-form URIs (e.g. http://) for proxy compatibility, including malformed ones. When request.url is "http://", the URL constructor throws TypeError: Invalid URL. Since there is no try-catch in the handler, the exception propagates as an uncaught exception and crashes the process.

The Prometheus metrics endpoint is unauthenticated by design (Prometheus scrapes it) and binds to 0.0.0.0 by default, meaning it is reachable by any network client that can connect to the metrics port.

Proof of Concept

Start any Node.js application with the Prometheus exporter running on the default port 9464, then send a single raw TCP packet:

echo -ne 'GET http:// HTTP/1.1\r\nHost: localhost\r\n\r\n' | nc localhost 9464

The process crashes immediately with:

TypeError: Invalid URL
    at new URL (...)
    at PrometheusExporter._requestHandler (...)

Overview

W3CBaggagePropagator.extract() in @<!-- -->opentelemetry/core does not enforce size limits when parsing inbound baggage HTTP headers. The W3C Baggage specification recommends a maximum of 8,192 bytes and 180 entries; these limits were only enforced on the outbound (inject()) path, not on the inbound (extract()) path. Parsing oversized baggage causes memory allocation proportional to the header size without any cap.

Impact

The practical availability impact for most Node.js deployments is limited. Node.js enforces a default --max-http-header-size of 16,384 bytes on the total combined size of all HTTP headers, constraining what an external attacker can deliver before the propagator is reached. Additionally, the header is already in memory (parsed by the HTTP layer) by the time it reaches the propagator - the additional allocation is the overhead of splitting into entry objects, not an unbounded read.

The risk is higher when transport-layer limits are absent - e.g., non-HTTP transports (messaging systems, custom TextMapGetter implementations) or deployments that have raised --max-http-header-size.

Remediation

Update @<!-- -->opentelemetry/core to version 2.8.0 or later. The fix enforces limits consistent with the W3C Baggage specification at the propagator level:

• Maximum total baggage size: 8,192 bytes
• Maximum number of entries: 180
• Maximum per-entry size: 4,096 bytes

Headers that exceed these limits are truncated at the point the limit is reached.

Workarounds

Ensure header size limits are configured at the server or gateway level. The default Node.js HTTP header limit (16 KB) mitigates external attack vectors independently of this fix. For non-HTTP transports receiving baggage from untrusted sources, validate input size before passing it to the propagator.

References

• W3C Baggage Specification - Limits
• opentelemetry-java: GHSA-rcgg-9c38-7xpx
• opentelemetry-go: GHSA-mh2q-q3fh-2475

Credit

Reported by tonghuaroot.

Overview

W3CBaggagePropagator.extract() in @<!-- -->opentelemetry/core does not enforce size limits when parsing inbound baggage HTTP headers. The W3C Baggage specification recommends a maximum of 8,192 bytes and 180 entries; these limits were only enforced on the outbound (inject()) path, not on the inbound (extract()) path. Parsing oversized baggage causes memory allocation proportional to the header size without any cap.

Impact

The practical availability impact for most Node.js deployments is limited. Node.js enforces a default --max-http-header-size of 16,384 bytes on the total combined size of all HTTP headers, constraining what an external attacker can deliver before the propagator is reached. Additionally, the header is already in memory (parsed by the HTTP layer) by the time it reaches the propagator - the additional allocation is the overhead of splitting into entry objects, not an unbounded read.

The risk is higher when transport-layer limits are absent - e.g., non-HTTP transports (messaging systems, custom TextMapGetter implementations) or deployments that have raised --max-http-header-size.

Remediation

Update @<!-- -->opentelemetry/core to version 2.8.0 or later. The fix enforces limits consistent with the W3C Baggage specification at the propagator level:

• Maximum total baggage size: 8,192 bytes
• Maximum number of entries: 180
• Maximum per-entry size: 4,096 bytes

Headers that exceed these limits are truncated at the point the limit is reached.

Workarounds

Ensure header size limits are configured at the server or gateway level. The default Node.js HTTP header limit (16 KB) mitigates external attack vectors independently of this fix. For non-HTTP transports receiving baggage from untrusted sources, validate input size before passing it to the propagator.

References

• W3C Baggage Specification - Limits
• opentelemetry-java: GHSA-rcgg-9c38-7xpx
• opentelemetry-go: GHSA-mh2q-q3fh-2475

Credit

Reported by tonghuaroot.

The same as the hono core Path traversal in serve-static on Windows via encoded backslash (%5C).

Summary

On Windows hosts, an encoded backslash (%5C) in the request path decodes to \, which the Windows path resolver treats as a separator. serve-static then resolves a single URL segment such as admin\secret.txt into a nested file under the root and serves it, letting an attacker read static files meant to be protected behind prefix-mounted middleware. Directory escape (..) remains blocked.

Details

The router splits paths only on /, so /admin%5Csecret.txt is one segment and middleware on /admin/* does not run. The serve-static guard rejects ./.. and consecutive separators but lets a lone \ through; on Windows the file resolver re-splits it into the protected subtree.

This affects Windows hosts serving static files via the Node, Bun, or Deno adapters that guard a static subtree with prefix-mounted middleware.

Impact

An unauthenticated attacker can read static files under a middleware-guarded prefix on Windows hosts. The read stays within the configured root; escape outside the root is not possible.

Overview

W3CBaggagePropagator.extract() in @<!-- -->opentelemetry/core does not enforce size limits when parsing inbound baggage HTTP headers. The W3C Baggage specification recommends a maximum of 8,192 bytes and 180 entries; these limits were only enforced on the outbound (inject()) path, not on the inbound (extract()) path. Parsing oversized baggage causes memory allocation proportional to the header size without any cap.

Impact

The practical availability impact for most Node.js deployments is limited. Node.js enforces a default --max-http-header-size of 16,384 bytes on the total combined size of all HTTP headers, constraining what an external attacker can deliver before the propagator is reached. Additionally, the header is already in memory (parsed by the HTTP layer) by the time it reaches the propagator - the additional allocation is the overhead of splitting into entry objects, not an unbounded read.

The risk is higher when transport-layer limits are absent - e.g., non-HTTP transports (messaging systems, custom TextMapGetter implementations) or deployments that have raised --max-http-header-size.

Remediation

Update @<!-- -->opentelemetry/core to version 2.8.0 or later. The fix enforces limits consistent with the W3C Baggage specification at the propagator level:

• Maximum total baggage size: 8,192 bytes
• Maximum number of entries: 180
• Maximum per-entry size: 4,096 bytes

Headers that exceed these limits are truncated at the point the limit is reached.

Workarounds

Ensure header size limits are configured at the server or gateway level. The default Node.js HTTP header limit (16 KB) mitigates external attack vectors independently of this fix. For non-HTTP transports receiving baggage from untrusted sources, validate input size before passing it to the propagator.

References

• W3C Baggage Specification - Limits
• opentelemetry-java: GHSA-rcgg-9c38-7xpx
• opentelemetry-go: GHSA-mh2q-q3fh-2475

Credit

Reported by tonghuaroot.