npm · undici
undici vulnerable to downstream response desynchronization via retry interceptor
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.
Patched in undici v6.28.0, v7.29.0, and v8.9.0. Users should upgrade to one of these versions or later.
interceptors.retry() for untrusted upstreams.Content-Length before forwarding a response body assembled or transformed by Undici.Is your project exposed to this? Stateward checks every dependency on every pull request and flags it only if your code actually reaches it.
Check my repoSources: CISA KEV (public domain), OSV.dev & GitHub Advisory Database (CC-BY-4.0), FIRST EPSS, NVD/CWE (public domain). Served live from the Stateward advisory database.