GHSA-8h4c-x2wg-6xp8

## 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