CVE-2026-69202

The Ember HTTP/2 implementation in http4s replenishes the inbound flow-control window based on bytes received from the wire rather than bytes actually consumed by the application, and buffers received DATA frames in an unbounded per-stream channel. As a result, HTTP/2 flow control provides no backpressure: an unauthenticated attacker can stream a large or endless request body to an Ember server built with .withHttp2 faster than the route drains it, or feed a large response body to an Ember client, forcing the connection to retain the entire payload in heap. The impact is remote denial of service through out-of-memory exhaustion of the JVM, with no confidentiality or integrity impact (CVSS 3.1: 7.5). This is the read-path mirror of the previously disclosed outbound queue issue (GHSA-8f3q-3jmv-7prw). No public proof of concept is known and there is no evidence of in-the-wild exploitation.

What to do: Disable HTTP/2 in Ember until a patched http4s release can be applied, which removes the vector entirely. Where HTTP/2 must stay enabled, wrap body-consuming routes in EntityLimiter (or an equivalent aggregate request-entity size limit) and ensure handlers fully drain request bodies with aggressive idle timeouts. Monitor JVM heap usage and long-lived HTTP/2 streams with large inbound bodies as indicators of attempted exploitation.