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).
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:
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.
Transfer-Encoding and
Content-Length (RFC says it MAY reject; many forward) and frames by
Content-LengthTransfer-Encoding
and Content-Length{
"cwe_ids": [
"CWE-444"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-15T19:53:44Z",
"nvd_published_at": null,
"severity": "CRITICAL"
}