Most recent entries from all

EUVD-2026-324122

fkie_cve-2026-49754

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 (HTTP/2 CONTINUATION flood).

When Mint's HTTP/2 receive path observes a HEADERS frame without the END_HEADERS flag, the unparsed header-block fragment is parked in conn.headers_being_processed, and every subsequent CONTINUATION frame on that stream is appended to the accumulator. Nothing in the receive path caps the accumulator: there is no per-stream size limit, no CONTINUATION frame-count limit, and max_header_list_size is only enforced on outgoing requests, never on inbound header blocks (its default is :infinity).

A malicious or compromised HTTP/2 server can stream an endless sequence of CONTINUATION frames (each up to the peer-advertised SETTINGS_MAX_FRAME_SIZE) and drive the client's iolist to arbitrary size, causing memory exhaustion and BEAM process death. A single connection to an attacker-controlled HTTP/2 endpoint is sufficient.

This issue affects mint: from 0.1.0 before 1.9.0.

GHSA-2p26-p43x-fhp8 — mint: Unbounded CONTINUATION/HEADERS frame accumulation (CONTINUATION flood)

Affected: Hex: mint

### Summary

Mint's HTTP/2 client accumulates `CONTINUATION` header-block fragments into a per-connection buffer with no cap on size or frame count. A malicious or compromised HTTP/2 server can drive the client's memory to arbitrary size by streaming an endless chain of `CONTINUATION` frames after a `HEADERS` frame that omits `END_HEADERS`, causing memory exhaustion and BEAM process death. A single connection to an attacker-controlled HTTP/2 endpoint is sufficient.

### Details

When Mint's HTTP/2 receive path observes a `HEADERS` frame without the `END_HEADERS` flag, `'Elixir.Mint.HTTP2':handle_headers/3` parks the unparsed header-block fragment in `conn.headers_being_processed`. Every subsequent `CONTINUATION` frame on that stream is then appended to the accumulator by `'Elixir.Mint.HTTP2':handle_continuation/3`.

Nothing in the receive path bounds this accumulator: there is no per-stream size cap, no `CONTINUATION` frame-count cap, and `max_header_list_size` is only enforced on outgoing requests (its default is `:infinity`, and the only enforcement helper inspects `server_settings` for request encoding, never inbound header blocks). Each `CONTINUATION` payload can be up to the peer-advertised `SETTINGS_MAX_FRAME_SIZE`, so the attacker can grow `headers_being_processed` to arbitrary size at line rate.

### PoC

1. Stand up a raw TCP server that speaks the HTTP/2 handshake. 2. After the client's request `HEADERS` arrives, respond with a `HEADERS` frame on stream 1 with `fla…