Most recent entries from all

EUVD-2026-361502

2026-10-05T19:33:34.779194+00:00

EUVD-2026-361502

fkie_cve-2026-54556

2026-10-05T19:33:34.779260+00:00

Http4s is a Scala interface for HTTP services. Prior to 0.23.35 and 1.0.0-M47, an unauthenticated HTTP/2 peer can cause an out-of-memory denial of service in the Ember backend with HTTP/2 enabled. The Hpack wrapper in ember-core/shared/src/main/scala/org/http4s/ember/core/h2/Hpack.scala concatenates HEADERS and CONTINUATION frame fragments and decodes them into a single List, but maxHeaderSize accounting does not include indexed headers or HPACK per-header overhead. A small compressed header block can therefore expand into a much larger decoded representation that remains in memory for processing. Servers exposed to untrusted HTTP/2 traffic and clients directed to an untrusted HTTP/2 server are affected, and concurrent malicious connections can exhaust the process heap. This issue is fixed in versions 0.23.35 and 1.0.0-M47.

GHSA-vmm3-xgcx-67hm — http4s has HTTP/2 Denial of Service with Ember Backend

2026-10-05T19:33:34.779321+00:00

Affected: Maven: org.http4s:http4s-ember-core_2.12, Maven: org.http4s:http4s-ember-core_2.13, Maven: org.http4s:http4s-ember-core_3

### Summary

http4s 0.23.x and 1.0 servers running ember with http2 enabled are vulnerable to a denial of service attack using a HPACK bomb vulnerability recently disclosed as affecting other http2 servers.

### Impact

Denial of Service: - Affects any http4s server running the ember backend with HTTP/2 enabled that is exposed to untrusted traffic. - Affects any http4s client running the ember backend with HTTP/2 enabled that can be directed to an untrusted server.

### Details

The issue occurs in the [Hpack wrapper](https://github.com/http4s/http4s/blob/c63fbff43dfe7e3bec25b789fd0a0027ec40ed62/ember-core/shared/src/main/scala/org/http4s/ember/core/h2/Hpack.scala#L54). Ember concatenates the header and continuation frames before decoding all headers at once. When the code decodes the attack payload, the relatively small packets decode to a significantly larger amount of data which is returned as a single List which is then held in memory for further processing. With enough concurrent connections (~5 with a 2GB heap in testing) this leads to an OOM, eg:

``` java.lang.OutOfMemoryError: Java heap space at scala.collection.mutable.ListBuffer.scala$collection$mutable$ListBuffer$$freshFrom(ListBuffer.scala:129) at scala.collection.mutable.ListBuffer.addAll(ListBuffer.scala:147) at scala.collection.mutable.ListBuffer.addAll(ListBuffer.scala:40) at scala.collection.mutable.Growable.$plus$plus$eq(Growable.scala:69) at scala.collection.mutable…