Description

undici's retry interceptor can append the body of a ranged retry response to bytes already delivered from an earlier partial response while still presenting the original response's status and headers. This happens when an upstream server delivers part of a body without a trustworthy resume checkpoint, for example a non-success response whose headers were already sent or a partial-content response with an unusable content range, then closes the connection and answers the resumed range request with more bytes. As a result the response body can be longer than the Content-Length that the application observes. An application that relays such a response to a downstream HTTP/1.1 peer without normalizing the framing can emit a body that exceeds the forwarded Content-Length, and the excess bytes can be interpreted as the start of a following response, which enables downstream response splitting or desynchronization. Exploitation requires an attacker-controlled upstream server and an application that forwards the response through a framing-sensitive path. This affects undici versions before 6.28.1, from 7.0.0 up to 7.29.1, and from 8.0.0 up to 8.10.2. Users should upgrade to undici 6.28.1, 7.29.1, or 8.10.2.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "3.7",
  "pubDate": "2026-09-04T18:17:50.020Z",
  "pubdate": "2026-09-04T18:17:50.020Z",
  "executiveSummary": "A request smuggling and response desynchronization vulnerability exists in the Undici HTTP client's retry interceptor.\nThe vulnerability occurs when an upstream server returns a partial response or an unreliable range response, causing the retry logic to improperly concatenate these segments.\nThis leads to an inconsistency between the actual transmitted response body and the advertised 'Content-Length' header.\nIf an application forwards this malformed response to a downstream HTTP/1.1 peer without re-normalizing the framing, the downstream peer may misinterpret the excess bytes as the start of a subsequent HTTP response.\nThis behavior facilitates response splitting or HTTP desynchronization attacks, potentially allowing an attacker to hijack downstream traffic.\nThe vulnerability is exploitable when an attacker controls the upstream server and the intermediary application performs insecure forwarding of HTTP responses.\nAffected products include Undici versions before 6.28.1, 7.0.0 to 7.29.1, and 8.0.0 to 8.10.2.",
  "technicalDetails": "The root cause of this vulnerability lies in the Undici retry interceptor's handling of partial or ranged HTTP responses. When an upstream server provides a segment of a response without a valid resume checkpoint—such as a non-success response where headers were already flushed, or a partial-content response containing an unusable or unexpected content range—and subsequently closes the connection, Undici's retry mechanism attempts to resume the request.\nUpon resumption, the interceptor appends the newly received bytes to the existing buffered response body. Critically, this concatenation occurs while maintaining the original response's metadata (status code and headers), effectively decoupling the HTTP framing from the actual payload size. Consequently, the delivered response body exceeds the value defined in the 'Content-Length' header.\nThe attack flow follows a specific sequence: First, an attacker-controlled upstream server initiates a communication sequence with an intermediary application using Undici. The server delivers a partial payload that forces the client-side retry interceptor into a state of concatenation. Second, the attacker triggers the retry logic to fetch additional bytes. Third, the resulting response, which contains a body payload larger than what the Content-Length header specifies, is passed by the intermediary application to a downstream HTTP/1.1 peer.\nBecause the downstream HTTP/1.1 peer relies on the 'Content-Length' header to demarcate the boundaries of the HTTP response, the excess bytes appended by the Undici retry interceptor are not consumed as part of the intended response. Instead, these trailing bytes remain in the communication buffer of the downstream peer. The peer then interprets these trailing bytes as the start of a new, attacker-crafted HTTP response.\nThis desynchronization allows an attacker to inject arbitrary content into the downstream connection, potentially leading to unauthorized data exposure, cross-site scripting (if the content is interpreted by a browser), or cache poisoning. Successful exploitation requires an attacker to control the upstream server, and for the application to be in a position where it blindly forwards or relays HTTP responses without normalizing or validating the framing consistency."
}