GHSA-6m4x-pp6q-5jmm Http4s Ember HTTP/2: unbounded inbound body buffering

• 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

Ember's HTTP/2 stack replenishes the inbound flow-control window based on bytes received off the wire, not bytes consumed by the application. Received DATA is buffered in an unbounded per-stream channel. Flow control therefore provides no backpressure: a peer can stream a large or unbounded body faster than the application drains it and the connection retains every payload in heap. This is the read-path mirror of the outbound queue issue. This affects an Ember receiving a request body and an Ember client receiving a response body from a hostile server. Impact Unauthenticated remote denial of service (OOM) against any Ember server built `.withHttp2` for a non-draining or slow-draining route, and against an Ember client consuming from a hostile or compromised server. Workarounds • Disable HTTP/2 to remove the vector entirely. • Apply an aggregate request-entity size limit (e.g. `EntityLimiter` middleware) on routes that consume the body. • Ensure handlers fully drain request bodies with aggressive idle timeouts.