EEF-CVE-2026-92103

## Summary

Allocation of Resources Without Limits or Throttling vulnerability in elixir-mint mint allows a malicious HTTP/2 server to make the client hold up to about 16 MiB per connection in frames it should reject, consuming client memory.

`Mint.HTTP2.Frame.decode_next/2` in `lib/mint/http2/frame.ex` compares a frame with the client's `max_frame_size` (16,384 bytes by default) only once the whole declared payload has arrived. Until then it returns `:more`, and `Mint.HTTP2` keeps every received byte in the connection buffer. A server can declare a frame length of up to 16,777,215 bytes and withhold the last byte, keeping roughly 1,024 times the advertised limit buffered for as long as the connection stays open. The server has to send every byte the client buffers, so there is no amplification, and the buffer stops at the 24-bit frame length limit.

This issue affects mint: from 0.1.0 before 1.11.0.

## Details

**1. Late size check.** `Mint.HTTP2.Frame.decode_next/2` calls `decode_next_raw/1`, whose binary pattern only matches once the full declared payload is present. The `max_frame_size` guard runs on the matched payload, so a partial frame of any declared length returns `:more`.

**2. Unbounded buffering.** On `:more`, `Mint.HTTP2.handle_new_data/3` stores the accumulated data in `conn.buffer`, and `maybe_concat_and_handle_new_data/2` prepends it to every later socket read, in both `stream/2` (active mode) and `recv/3` (passive mode). Nothing caps the buffer.

**3. No release.** Mint has no idle timer. In active mode the buffer is held until the caller closes the connection. In passive mode a `recv/3` timeout closes it, but a server that sends a byte within each timeout keeps it open. `max_frame_size` can't be set below the 16,384-byte protocol minimum, and no setting moves the check earlier.

## Proof of concept

1. Build an HTTP/2 frame header whose 24-bit length field declares 1,000,000 bytes, above the default `max_frame_size` of 16,384. 2. Pass the header followed by 16,384 and then 512,000 payload bytes to `Mint.HTTP2.Frame.decode_next/2` with a limit of 16,384. Each call returns `:more`, which makes `Mint.HTTP2` keep the bytes in `conn.buffer`. 3. Pass the header with the complete 1,000,000-byte payload. Only this call returns `{:error, :payload_too_big}`.

## Impact

A malicious or compromised HTTP/2 server can make a Mint client keep up to about 16 MiB per connection buffered, and keep it there while the connection stays open. Clients that hold many HTTP/2 connections to attacker-influenced origins, such as webhook senders, crawlers and proxies, can run out of memory.

## Workarounds

Connect to untrusted origins over HTTP/1 only, with `protocols: [:http1]` in `Mint.HTTP.connect/4`, which never runs the HTTP/2 frame decoder. Finch and Req pools use HTTP/1 only unless `:http2` is added to their `protocols` option.