GHSA-8h4c-x2wg-6xp8: Maven/org.http4s:http4s-ember-core_3 vulnerability
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
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
maven/org.http4s:http4s-ember-core_3to a version that resolves this vulnerability.Fixed in 1.0.0-M47 - Upgrade
Upgrade
maven/org.http4s:http4s-ember-core_2.13to a version that resolves this vulnerability.Fixed in 1.0.0-M47 - Upgrade
Upgrade
maven/org.http4s:http4s-ember-core_3to a version that resolves this vulnerability.Fixed in 0.23.35 - Upgrade
Upgrade
maven/org.http4s:http4s-ember-core_2.13to a version that resolves this vulnerability.Fixed in 0.23.35 - Upgrade
Upgrade
maven/org.http4s:http4s-ember-core_2.12to a version that resolves this vulnerability.Fixed in 0.23.35 - Configuration
Disable backend keep-alive between the intermediary and Ember to prevent request smuggling across a pooled HTTP connection.
Ember server HTTP keep-alive between intermediary and Ember (backend keep-alive) = disable - Compensating control
Use an intermediary (e.g., caching proxy / ACL/auth layer) configuration that strictly rejects requests carrying both a Transfer-Encoding header and a Content-Length header (RFC 9112 §6.1) to mitigate CL.TE request smuggling.
Event History
Frequently Asked Questions
Which deployment patterns are exposed on the server side?
An ember-server origin is exposed when it sits behind an intermediary that forwards both Transfer-Encoding and Content-Length over a keep-alive backend connection, while the intermediary frames using Content-Length and Ember frames using chunked encoding.
What must an attacker be able to send to exploit the server-side issue?
The attacker needs to send a request containing both Transfer-Encoding and Content-Length headers through an intermediary with the described forwarding and framing behavior. The resulting framing disagreement enables CL.TE request smuggling.
When is ember-client affected?
ember-client is affected on the response path when an upstream sends both headers and the client uses pooled connections. The parser desynchronization can affect the pooled client connection.
Which Maven artifacts are identified by the advisory?
The advisory identifies maven/org.http4s:http4s-ember-core_3 and maven/org.http4s:http4s-ember-core_2.13.