CVE-2026-69202 in Http4s
Summary
by MITRE • 09/15/2026
Http4s is a Scala interface for HTTP services. Prior to 0.23.35 and 1.0.0-M47, Ember’s HTTP/2 flow-control window is replenished according to bytes received from the network rather than bytes consumed by the application, while each stream stores DATA in an unbounded channel. A hostile peer can therefore send a body faster than a slow or non-draining application consumes it, retaining payloads in heap on an ember-server or ember-client configured with withHttp2. The patch bounds the per-stream H2Connection body channel so application consumption applies backpressure. This issue is fixed in versions 0.23.35 and 1.0.0-M47.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/15/2026
The vulnerability identified within Http4s, specifically affecting its Ember HTTP client and server components prior to versions 0.23.35 and 1.0.0-M47, represents a critical resource management flaw rooted in the implementation of HTTP/2 flow control mechanisms. Http4s serves as a functional Scala interface for building HTTP services, relying on the Ember component for its underlying network transport layer. The core technical deficiency lies in how the system handles data buffering and backpressure during HTTP/2 stream processing. In a correctly implemented HTTP/2 connection, flow control ensures that a sender does not overwhelm a receiver by regulating the rate of data transmission based on the receiver's available buffer space. However, in these vulnerable versions, Ember replenishes its internal flow-control window according to bytes received from the network rather than bytes actually consumed and processed by the application layer. This discrepancy creates a significant lag between network-level acknowledgment and application-level processing capacity.
This architectural flaw is compounded by the fact that each HTTP/2 stream stores incoming DATA frames in an unbounded channel within the heap memory of the JVM. Because the flow-control window expands based on raw network ingress rather than actual consumption, a hostile peer can exploit this behavior to force the server or client into accepting arbitrarily large amounts of data without triggering backpressure signals upstream. If an application is slow to process incoming requests or fails to drain the input stream entirely, the Ember component will continue to accumulate payloads in memory indefinitely. This mechanism effectively bypasses standard HTTP/2 flow control protections designed to prevent resource exhaustion attacks.
The operational impact of this vulnerability is severe, primarily manifesting as a Denial of Service (DoS) condition through heap exhaustion. An attacker can send body data at a rate significantly faster than the application consumes it, causing the JVM heap to fill up with retained payloads. As memory usage climbs, the system may experience increased garbage collection pauses, latency spikes, and eventually an OutOfMemoryError that crashes the service or client instance. This is particularly dangerous in server-side deployments where multiple concurrent connections can be exploited simultaneously to accelerate resource depletion. The issue affects both ember-server and ember-client configurations explicitly enabled with HTTP/2 support via the withHttp2 setting, making any Scala-based web application using these versions susceptible to remote memory exhaustion attacks.
To mitigate this risk, organizations must upgrade Http4s to version 0.23.35 or later for the 0.23.x branch, or version 1.0.0-M47 and above for the newer release track. The patch addresses the root cause by bounding the per-stream H2Connection body channel, ensuring that application consumption correctly applies backpressure to the network layer. This alignment ensures that flow-control windows accurately reflect the actual processing capacity of the application rather than just network reception rates. From a defensive posture perspective, this vulnerability aligns with CWE-400, which describes Uncontrolled Resource Consumption, and specifically relates to improper handling of input data leading to resource exhaustion. In terms of offensive tactics, this flaw can be leveraged using techniques categorized under MITRE ATT&CK T1498, Network Denial of Service, where an attacker overwhelms a target with excessive traffic or malformed requests that consume disproportionate resources. Administrators should verify their dependency versions and apply the patch immediately to restore proper flow control semantics and prevent potential service disruption through heap exhaustion attacks.