GHSA-6m4x-pp6q-5jmm
Http4s Ember HTTP/2: unbounded inbound body buffering
Packages
| Ecosystem | Package | Affected | Fixed in |
|---|---|---|---|
| Maven | org.http4s:http4s-ember-core_2.12 | < 0.23.35 | 0.23.35 |
| Maven | org.http4s:http4s-ember-core_2.13 | < 0.23.35 | 0.23.35 |
| Maven | org.http4s:http4s-ember-core_3 | < 0.23.35 | 0.23.35 |
| Maven | org.http4s:http4s-ember-core_2.13 | >= 1.0.0-M1, < 1.0.0-M47 | 1.0.0-M47 |
| Maven | org.http4s:http4s-ember-core_3 | >= 1.0.0-M1, < 1.0.0-M47 | 1.0.0-M47 |
Details
As written in the advisory (Markdown source, shown as plain text).
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](https://github.com/http4s/http4s/security/advisories/GHSA-8f3q-3jmv-7prw).
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.
References
External links from the advisory. They lead to third-party sites.