Most recent entries from all

EUVD-2026-324121

fkie_cve-2026-48862

Allocation of Resources Without Limits or Throttling vulnerability in elixir-mint Mint allows attacker-controlled HTTP/2 servers to exhaust memory in a Mint client via PUSH_PROMISE flooding.

In lib/mint/http2.ex, Mint.HTTP2.decode_push_promise_headers_and_add_response/5 inserts a :reserved_remote entry into conn.streams for every promised stream ID. The neighbouring Mint.HTTP2.assert_valid_promised_stream_id/2 only verifies that the promised ID is even and not already present; client_settings.max_concurrent_streams is not consulted at promise time. The concurrency cap is only checked when the response HEADERS for the promised stream arrive, so a server that emits PUSH_PROMISE frames and withholds the matching HEADERS never trips that check.

HTTP/2 server push is accepted by default (client_settings.enable_push defaults to true). A single long-lived HTTP/2 connection to a hostile server lets that server pin one conn.streams entry per PUSH_PROMISE frame it sends, with no upper bound, until the client process runs out of memory.

This issue affects mint: from 0.2.0 before 1.9.0.

GHSA-g586-ccqf-7x4r — mint: Unbounded streams map growth via PUSH_PROMISE without follow-up HEADERS

Affected: Hex: mint

### Summary

Mint's HTTP/2 client accepts `PUSH_PROMISE` frames from any server it connects to and inserts every promised stream into a per-connection map without consulting `max_concurrent_streams`. A malicious or compromised HTTP/2 server can flood the client with `PUSH_PROMISE` frames and withhold the matching response `HEADERS`, pinning one map entry per frame indefinitely until the client process runs out of memory.

### Details

`'Elixir.Mint.HTTP2':handle_push_promise/3` in `lib/mint/http2.ex` dispatches every inbound `PUSH_PROMISE` frame to `'Elixir.Mint.HTTP2':decode_push_promise_headers_and_add_response/5`, which inserts a `:reserved_remote` entry into `conn.streams` for the promised ID. The only validation applied is that the promised ID is even and not already present; `client_settings.max_concurrent_streams` is not consulted at promise time.

The concurrency cap is only checked when the response `HEADERS` for the promised stream arrive. A server that emits `PUSH_PROMISE` frames and never sends the matching `HEADERS` never trips that check, and the existing tally counts only streams in open states, not `:reserved_remote` entries.

HTTP/2 server push is accepted by default (`client_settings.enable_push` defaults to `true`), so no application opt-in is required. A single long-lived HTTP/2 connection to a hostile server lets it pin one `conn.streams` entry per `PUSH_PROMISE` frame, with no upper bound.

### PoC

1. Stand up a raw TCP HTTP/2 server that completes the…