GHSA-8f3q-3jmv-7prw Http4s Ember HTTP/2 has an unbounded outbound frame queue

• 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_3: >= 1.0.0-M1, < 1.0.0-M47 → fixed in 1.0.0-M47 • Maven org.http4s:http4s-ember-core_2.13: >= 1.0.0-M1, < 1.0.0-M47 → fixed in 1.0.0-M47

Ember's HTTP/2 connection serializes all outgoing frames through a single unbounded queue drained by one writer fiber (`writeLoop`). When the write side stalls, any frames the connection keeps producing accumulate in that queue without limit. The peer can drive this cheaply because the connection emits a control frame in response to inbound frames it does not flow-control: one `PING` ACK per `PING`, one `SETTINGS` ACK per `SETTINGS`, and a `WINDOW_UPDATE` per inbound DATA. A single unauthenticated connection can therefore exhaust heap and OOM the process. This affects an ember server (malicious client) and an ember client (malicious/compromised server that floods the client and stops reading its ACKs). Impact Unauthenticated remote denial of service (OOM) against any ember server built `.withHttp2`, from a single connection, at negligible attacker cost (tiny control frames). Also affects an ember client talking to a hostile HTTP/2 server. Preconditions • Ember server or client built `.withHttp2`, speaking to a hostile or compromised peer. Workarounds • Disable HTTP/2 (do not call `.withHttp2`).