vulnerability / NVI-00015325 / Revision 1
Http4s Ember HTTP/2: unbounded inbound body buffering
GitHub lists this reviewed advisory for org.http4s:http4s-ember-core_2.12, org.http4s:http4s-ember-core_2.13, org.http4s:http4s-ember-core_3, org.http4s:http4s-ember-core_2.13, org.http4s:http4s-ember-core_3. Published version ranges and source prerequisites are shown below; this is not an inspection of a visitor’s application.
This report has not inspected your inventory, configuration, deployed build, reachability or evidence. A catalog listing and a severity score do not establish exposure or compromise.
01 / Meaning
Why it matters
Published affected context helps an owner decide what evidence to gather. This report has not examined your application.
7.5 high
GitHub source severity; exploitability and local consequence require separate evidence.
As of · GitHub Advisory Database
02 / Applicability
The affected context
Affected versions, configuration prerequisites and known exclusions are public. Confirm each one against the deployed service.
org.http4s:http4s-ember-core_2.12
source listed<= 0.23.34
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.
org.http4s:http4s-ember-core_2.13
source listed<= 0.23.34
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.
org.http4s:http4s-ember-core_3
source listed<= 0.23.34
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.
org.http4s:http4s-ember-core_2.13
source listed>= 1.0.0-M1, <= 1.0.0-M46
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.
org.http4s:http4s-ember-core_3
source listed>= 1.0.0-M1, <= 1.0.0-M46
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.
03 / Response
What to do next
- investigate
Identify the exact component and deployed version, examine the linked publisher’s conditions, and retain evidence of any mitigation.
Confirm current vendor support, compatibility and deployment evidence. This report has not tested a fix in your system. GitHub Advisory Database
A fixed release is not deployment evidence.
Check current vendor support and compatibility. After making a change, verify the deployed build and relevant runtime conditions. Keep the evidence, owner and time. An updated lockfile alone does not prove what is running.
04 / Limits
What this report cannot establish
- Customer inventory, deployment, reachability and exploitation have not been inspected.
05 / Provenance
Sources you can inspect
Each assertion retains its source. Mirrored records may repeat one underlying publisher; additional links are not independent corroboration.
- GHSA-6m4x-pp6q-5jmm ↗
GitHub Advisory Database · vendor advisory
Observed . GitHub Advisory Database; CC-BY-4.0. Each advisory links its original attribution. Null normalizes fields.
Public revision history
Only published revisions appear here. Routine fetches do not create a material-change event.
- Revision 1 ·
First indexed by Null; source disclosure date is shown separately.