Http4s Ember accepts Transfer-Encoding combined with Content-Length (CL.TE request smuggling)

Summary

Ember's HTTP/1.1 request parser does not reject a message that carries both a
Transfer-Encoding and a Content-Length header. RFC 9112 §6.1 requires a
server to treat such a message as a framing error and close the connection.
An intermediary that follows the RFC's CL-strip-and-forward path (or that
prioritises Content-Length) will frame the body differently from Ember,
enabling HTTP request smuggling (CL.TE).

Impact

Server

Request smuggling when ember-server is an origin behind an intermediary that
forwards both headers over a keep-alive backend connection and frames by
Content-Length while Ember frames by chunked:

• Front-end security bypass: the smuggled request reaches paths the
  intermediary's ACL/auth layer would have blocked, with attacker-chosen
  method and headers.
• Cross-user request hijack: a dangling smuggled prefix concatenates with the
  next victim's request on the shared backend socket, capturing its headers.
• Cache poisoning: the smuggled response is associated with the next request
  key in a caching proxy.

Client

ember-client shares the same parser on the response path. An upstream that
sends both headers can desync a pooled client connection. This requires a
malicious or compromised upstream.

Preconditions

• Unauthenticated remote attacker (server)
• ember-server as origin behind a keep-alive intermediary
• Intermediary forwards a request carrying both Transfer-Encoding and
  Content-Length (RFC says it MAY reject; many forward) and frames by
  Content-Length
• Malicious or compromised upstream (client)

Workarounds

• Intermediary strictly rejects requests carrying both Transfer-Encoding
  and Content-Length
• Intermediary buffers and re-encodes request bodies
• Disable backend keep-alive between the intermediary and Ember