GHSA-jrpm-956j-96jg Http4s: Ember chunk parser lenience (TE.TE request smuggling)

• Maven org.http4s:http4s-ember-core_2.12: < 0.23.35 → fixed in 0.23.35 • Maven org.http4s:http4s-ember-core_2.13: < 0.23.35 → fixed in 0.23.35 • Maven org.http4s:http4s-ember-core_3: < 0.23.35 → fixed in 0.23.35 • Maven org.http4s:http4s-ember-core_2.13: >= 1.0.0-M1, < 1.0.0-M47 → fixed in 1.0.0-M47 • Maven org.http4s:http4s-ember-core_3: >= 1.0.0-M1, < 1.0.0-M47 → fixed in 1.0.0-M47

Summary Ember's chunk decoder parses the size token leniently: it strips leading and trailing whitespace and accepts a leading `+` or `-` sign. RFC9112 §7.1 defines `chunk-size = 1*HEXDIG`. An intermediary that parses the chunk boundary differently (or rejects it) will disagree with Ember on request framing, enabling HTTP request smuggling (TE.TE). Impact Server Request smuggling (TE.TE) when ember-server is an origin behind an intermediary that forwards the body verbatim but interprets the malformed chunk sizes differently • Front-end security bypass: the smuggled request reaches paths the intermediary might have blocked, with attacker-chosen method and headers. • Cache poisoning: the smuggled response is associated with the next request key in a caching proxy. • Request queue hijack: Client ember-client has the same leniencies on the response path, which enables response smuggling when http4s is used as a gateway. This is less severe, as it requires a malicious or compromised upstream rather than an anonymous remote client. Preconditions • Unauthenticated remote attacker (server) • ember-server as origin behind a keep-alive intermediary • Malicious or compromised upstream (client) • Intermediary or upstream forwards chunked bodies without re-encoding and disagrees with Ember on `+` prefix, `-` prefix, or leading and trailing octets rather than rejecting. Workarounds • Intermediary strictly rejects malformed chunk sizes • Intermediary buffers and re-encodes request bodies References • RFC9112 §7.1: Chunked Transfer Coding