Description

undici's retry handler can leave an already-exposed response body pending forever. When a server returns a successful response that declares a Content-Length, sends only part of the body, and closes the connection, the retry handler retries the request. If the retry returns a non-retryable status such as 400, the handler forwards that new response downstream and replaces its internal response stream, but the original response body that the application still holds is never ended or destroyed. As a result calls that read that body never settle, and the configured body timeout does not fire because its timer is tied to the connection parser rather than the orphaned body. An attacker-controlled server can trigger this with two short responses without keeping a connection open, and repeated requests accumulate pending promises and streams that can exhaust application concurrency or memory. This affects undici versions from 7.11.0 up to 7.29.1 and from 8.0.0 up to 8.10.2. Users should upgrade to undici 7.29.1 or 8.10.2.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.9",
  "pubDate": "2026-09-04T18:17:49.733Z",
  "pubdate": "2026-09-04T18:17:49.733Z",
  "executiveSummary": "The undici HTTP client library contains a vulnerability where the retry handler fails to properly terminate orphaned response streams. This issue allows a malicious server to cause resource exhaustion by triggering incomplete response bodies that remain pending indefinitely. The vulnerability affects undici versions 7.11.0 through 7.29.0 and 8.0.0 through 8.10.1.\nWhen a server provides a Content-Length header but terminates the connection prematurely, the undici retry handler initiates a new request. If the subsequent response is non-retryable (e.g., a 400 Bad Request), the handler replaces the internal stream reference while failing to close or destroy the original pending body. This results in hanging promises and uncollected streams.\nImpact includes memory leakage and potential application-level concurrency exhaustion. An attacker-controlled server can weaponize this by sending two consecutive short responses, effectively leaking resources with every attempt. No authentication is required for exploitation as it relies on the processing of server responses. Remediation requires upgrading to versions 7.29.1 or 8.10.2.",
  "technicalDetails": "The vulnerability resides within the undici retry handler logic, specifically in its handling of asynchronous response streams following a failed or interrupted initial request. When a server issues a response containing a Content-Length header but closes the underlying TCP connection before the full body is received, the retry mechanism is triggered.\nThe flaw manifests when the subsequent retry attempt returns a non-retryable status code, such as a 400 Bad Request. Upon receiving this secondary response, the retry handler correctly updates the internal response stream pointer to point to the new data. However, the handler fails to call .destroy() or close the original stream object that was already provided to the calling application.\nBecause the original stream remains in an unclosed state, any downstream consumers awaiting data from that stream will find their promises never settling. Furthermore, the configured body timeout mechanism, which is anchored to the connection parser rather than the orphaned stream object, fails to trigger. This leaves the orphaned stream in a 'pending' state indefinitely.\nAn attacker can exploit this behavior by orchestrating a server response sequence designed to trigger retries. By sending two short, malformed responses that violate the protocol expectation set by the Content-Length header, the attacker forces the client to accumulate orphaned, unended streams in memory. Since these streams are never garbage collected due to pending references, repeated requests lead to a linear growth in memory consumption and exhaustion of the client application's concurrency limits.\nThis vulnerability is particularly insidious because it bypasses standard timeout configurations. Since the timer is associated with the connection parser—which has already been reassigned or disconnected—the cleanup logic is never executed for the leaked stream. The lack of proper stream management prevents the runtime from reclaiming the associated memory buffers, leading to a stable Denial of Service (DoS) state over time as the heap becomes saturated with leaked object references.\nThe affected component is the undici library's retry logic, specifically versions 7.11.0 to 7.29.0 and 8.0.0 to 8.10.1. Exploitation requires no special privileges or authentication, provided the application is configured to perform requests against a server controlled or intercepted by the attacker."
}