GHSA-8f3q-3jmv-7prw: High severity maven/org.http4s:http4s-ember-core_2.13 vulnerability
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 WINDOWUPDATE 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).
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- 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 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 by not calling `.withHttp2` when building the Ember HTTP/2 connection (workaround for heap exhaustion/OOM via unbounded write queue).
Ember HTTP/2 (client/server) .withHttp2 = do not enable (do not call .withHttp2) - Compensating control
If disabling HTTP/2 is not immediately possible, mitigate the unauthenticated DoS by isolating or restricting network access so untrusted peers cannot open connections to Ember HTTP/2 endpoints (since a single unauthenticated connection can exhaust heap/OOM).
Event History
Frequently Asked Questions
Which deployments are exposed?
Any Ember server or client built with .withHttp2 is exposed when it communicates with a hostile or compromised HTTP/2 peer. Servers can be attacked by an unauthenticated malicious client, while clients are affected by a malicious or compromised server.
What does an attacker need to do to trigger the denial of service?
An attacker needs only one HTTP/2 connection and does not need authentication. They can send inexpensive PING, SETTINGS, or DATA frames while ceasing to read the connection's outbound ACKs or WINDOW_UPDATE frames, causing the unbounded outgoing queue to consume heap until the process runs out of memory.
Are default HTTP/2 deployments affected?
The affected condition is explicitly enabling HTTP/2 with .withHttp2. Deployments that do not call .withHttp2 are not described as affected.
What can be done if patching is not immediately possible?
Disable HTTP/2 by not calling .withHttp2. This prevents the vulnerable HTTP/2 connection behavior.