GHSA-6m4x-pp6q-5jmm: High severity maven/org.http4s:http4s-ember-core_3 vulnerability
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
maven/org.http4s:http4s-ember-core_3to a version that resolves this vulnerability.Fixed in 1.0.0-M47 - Upgrade
Upgrade
maven/org.http4s:http4s-ember-core_2.13to a version that resolves this vulnerability.Fixed in 1.0.0-M47 - Upgrade
Upgrade
maven/org.http4s:http4s-ember-core_3to a version that resolves this vulnerability.Fixed in 0.23.35 - Upgrade
Upgrade
maven/org.http4s:http4s-ember-core_2.13to a version that resolves this vulnerability.Fixed in 0.23.35 - Upgrade
Upgrade
maven/org.http4s:http4s-ember-core_2.12to a version that resolves this vulnerability.Fixed in 0.23.35 - Configuration
Disable HTTP/2 (i.e., do not use .withHttp2) to remove the OOM/DoS vector.
Ember HTTP/2 (as used with .withHttp2) .withHttp2 / HTTP/2 enablement = disable - Compensating control
Apply an aggregate request-entity size limit (e.g., via a request/entity limit) so the server rejects overly large/unbounded request bodies.
- Compensating control
Ensure handlers fully drain request bodies; use aggressive idle timeouts so slow-draining/non-draining routes cannot retain unbounded buffered payloads in heap.
Event History
Frequently Asked Questions
Which deployments are exposed?
Ember servers built with .withHttp2 are exposed when a route drains request bodies slowly or does not drain them. Ember clients are also exposed when receiving responses from a hostile or compromised server.
What does an attacker need to do to trigger the denial of service?
No authentication or user interaction is required. The peer sends an HTTP/2 DATA stream faster than the application consumes it, causing the received payload to accumulate in an unbounded per-stream buffer until heap memory is exhausted.
Is HTTP/2 required for exploitation?
Yes. The described vector is in Ember's HTTP/2 flow-control handling; disabling HTTP/2 removes this vector entirely.
What can be done while patching is not possible?
Disable HTTP/2, or apply an aggregate request-entity size limit such as EntityLimiter on routes that consume request bodies. Handlers should also fully drain request bodies and use aggressive idle timeouts.