CVE-2026-48862: Unbounded Resource Allocation via HTTP/2 PUSH_PROMISE Flooding in Mint

The Elixir package mint is a highly leveraged HTTP/1 and HTTP/2 client designed for the Erlang VM (BEAM). It provides low-level process-less connection management and is frequently utilized in high-concurrency environments. By default, Mint supports the HTTP/2 Server Push specification (RFC 7540 / RFC 9113), which allows a server to preemptively send resources to a client that it anticipates the client will request.

Under default configuration parameters, Server Push is automatically enabled (client_settings.enable_push defaults to true). When communicating over an HTTP/2 connection, a server initiates a push stream by transmitting a PUSH_PROMISE frame. This frame contains a promised stream ID and request headers. The receipt of this frame transitions the promised stream to a :reserved_remote state on the client side.

In vulnerable versions of Mint, the library fails to limit the number of streams a server can transition into this :reserved_remote state. A malicious or compromised server can leverage this state-tracking mechanism to execute a resource exhaustion attack. By sending a continuous stream of PUSH_PROMISE frames without ever fulfilling them, the server forces the client to allocate heap memory for each stream, eventually leading to process termination via an Out-Of-Memory (OOM) event.

The root cause of CVE-2026-48862 is an allocation of resources without limits (CWE-770) within the HTTP/2 frame parsing architecture. Specifically, the flaw lies in lib/mint/http2.ex inside the private function decode_push_promise_headers_and_add_response/5.

When Mint receives a PUSH_PROMISE frame, it immediately decodes the header block fragment (HBF) to keep the HPACK dynamic table state synchronized with the server. After decoding, the library constructs a stream representation map and inserts it into the active connection streams dictionary (conn.streams). At this point, the stream's state is designated as :reserved_remote.

While Mint tracks the max concurrency limit set by the client via client_settings.max_concurrent_streams, this check was historically only performed when the actual response HEADERS for the promised stream arrived. Because the state transition from :reserved_remote to an active state requires the receipt of these response headers, a server can bypass the concurrency cap entirely. By emitting an arbitrary number of PUSH_PROMISE frames and deliberately withholding the matching response HEADERS, the server ensures that the concurrency validation logic is never reached. Consequently, the size of the conn.streams map increases linearly and without limit for every frame received.

The official patch (Commit 70b97b6a5209fb288b0e04d8e657dda26c59de67) resolved the vulnerability by introducing pre-allocation accounting of the :reserved_remote streams.

In the vulnerable implementation, any valid PUSH_PROMISE frame was directly added to the stream collection without calculating current reserved limits:

# VULNERABLE CODE PATH
promised_stream = %{
  id: promised_stream_id,
  ref: make_ref(),
  state: :reserved_remote,
  send_window_size: conn.server_settings.initial_window_size,
  receive_window_size: conn.client_settings.initial_window_size,
  receive_window_remaining: conn.client_settings.initial_window_size,
  received_first_headers?: false
}
conn = put_in(conn.streams[promised_stream.id], promised_stream)

The patch addresses this by adding a new tracking metric, reserved_server_stream_count, to the core %Mint.HTTP2{} struct. When a PUSH_PROMISE frame is parsed, the combined total of active and reserved streams is calculated and checked against the client's limits at promise time:

# PATCHED CODE PATH
# First, the HPACK table is synchronized by decoding the headers
{conn, headers} = decode_hbf(conn, hbf)
 
# Calculate total streams currently occupied by the server
server_stream_count = conn.open_server_stream_count + conn.reserved_server_stream_count
 
# Enforce max concurrency before allocating the state map
if server_stream_count >= conn.client_settings.max_concurrent_streams do
  conn = refuse_promised_stream(conn, promised_stream_id)
  {conn, responses}
else
  promised_stream = %{
    id: promised_stream_id,
    ref: make_ref(),
    state: :reserved_remote,
    # ... (window settings)
  }
  conn = put_in(conn.streams[promised_stream.id], promised_stream)
  conn = update_in(conn.reserved_server_stream_count, &(&1 + 1))
  new_response = {:push_promise, stream.ref, promised_stream.ref, headers}
  {conn, [new_response | responses]}
end

Additionally, the patch safely decrements the reserved_server_stream_count in lib/mint/http2.ex whenever a stream transition occurs or when a connection reset resets a reserved stream. If the limit is exceeded, refuse_promised_stream/2 is executed, which encodes and transmits an HTTP/2 RST_STREAM frame with the error code :refused_stream back to the server. The refused stream is never committed to the client's in-memory dictionary, bounding memory usage.

An attacker must construct a malicious HTTP/2 server or compromise an upstream server to execute this attack. The target (the Elixir client) must initiate an outbound connection to this hostile endpoint. No user interaction or specialized privileges are required to perform the attack once the network connection is established.

Upon receiving the client's initial request, the malicious server transmits a rapid sequence of PUSH_PROMISE frames. Under the HTTP/2 specification, the promised stream identifier must be an even integer and must not have been previously utilized. The server generates thousands of sequential, even stream IDs (e.g., 4, 6, 8, 10, ...).

For each PUSH_PROMISE sent, the server specifies headers but intentionally never transmits the corresponding response headers that would open and subsequently close the stream. As the client parses each frame, its conn.streams map grows. Within the BEAM virtual machine, each entry in this map allocates heap space for the tracking metadata and a unique reference created via make_ref(). Under a sustained flood, the memory footprint of the Elixir process hosting the connection expands exponentially, exhausting system memory and causing the OS kernel or the BEAM runtime to terminate the application process.

While the applied patch successfully mitigates unbounded stream allocation, secondary vectors must be evaluated by security engineers maintaining HTTP/2 client infrastructures.

First, because the client is required to maintain HPACK dynamic table state synchronization, it must execute decode_hbf/2 on every incoming PUSH_PROMISE frame, including those it immediately refuses. A malicious server could exploit this requirement by sending an endless stream of highly compressed, mathematically complex headers (HPACK dynamic table manipulations or 'HPACK Bombs'). Although the streams are discarded, the CPU cycles spent decoding the HBF and the temporary heap allocations needed during processing present a secondary Denial of Service vector.

Second, an attacker could implement a slow-concurrency attack. By opening exactly the maximum allowed concurrent streams (e.g., 100 streams) and keeping them in the :reserved_remote state permanently, the server can exhaust the client's push capacity. While this does not cause memory exhaustion, it results in a logical Denial of Service for any subsequent legitimate server push frames.

To fully remediate CVE-2026-48862, organizations must upgrade Mint to version 1.9.0 or higher. This version introduces the proactive concurrency limit verification and counts reserved streams against the client-side concurrency cap.

If upgrading the library is not immediately feasible due to deployment or dependency pinning constraints, administrators must disable HTTP/2 Server Push. This can be configured globally or per-connection by setting the :enable_push option to false within the Mint connection parameters:

# Workaround configuration to disable server push
{:ok, conn} = Mint.HTTP.connect(:https, "endpoint.example.com", 443, [
  client_settings: [enable_push: false]
])

When :enable_push is disabled, Mint's frame decoder automatically drops or rejects any incoming PUSH_PROMISE frames at the frame-parsing layer, returning a protocol error to the server. This prevents the execution of the vulnerable state-allocation code path, completely neutralizing the attack vector.