undici vulnerable to downstream response desynchronization via retry interceptor

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:

```http

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

Weakness classes: CWE-444 (Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling'))

Source: GHSA-8xcm-r25x-g524 · GitHub Advisory Database (CC-BY-4.0) — printed from a structured Sanity dataset. ← Back to the front page