EEF-CVE-2026-91043

## Summary

Allocation of Resources Without Limits or Throttling vulnerability in elixir-mint mint allows a malicious HTTP/2 server to exhaust memory on the client host and cause a denial of service.

`Mint.HTTP2` enforces the client's `max_header_list_size` setting only on the compressed size of an inbound header block, while RFC 9113 section 6.5.2 defines the limit on the decoded header list. An HPACK indexed field costs one byte on the wire and decodes to a dynamic table entry of up to 4 KB, and `join_cookie_headers/1` in `lib/mint/http2.ex` copies every `cookie` value of a response into one new binary. A header block under the default 256 KB wire limit therefore makes the client allocate about 1 GB for a single response, and several such responses in one delivery exhaust the memory of the process that owns the connection or of the whole VM.

This issue affects mint: from 1.1.0 before 1.11.0.

## Details

**1. Compressed-size check only.** `Mint.HTTP2.assert_header_block_within_max_size/2` compares the accumulated `HEADERS` plus `CONTINUATION` bytes with `client_settings.max_header_list_size`, which bounds a `CONTINUATION` chain but not the decoded size. After `HPAX.decode/2` returns, `decode_hbf_and_add_responses/5` passes the header list to `handle_decoded_headers_for_stream/5` without measuring it. The only implementation of the RFC 9113 section 6.5.2 formula, `assert_headers_smaller_than_max_header_list_size/2`, applies the server's setting to headers Mint sends.

**2. Indexed-field expansion.** An HPACK indexed field (RFC 7541 section 6.1) is one byte for small table indexes and refers to a dynamic table entry of up to 4 KB. HPAX returns one shared binary per reference, so the decoded list itself stays small.

**3. Cookie join.** `join_cookie_headers/1` runs `Enum.map_join/3` over every `cookie` value, copying each shared value into one contiguous binary. The dynamic table entry persists for the connection, so the same block can answer every open stream, and `Mint.HTTP.stream/2` returns all responses parsed from one delivery together.

## Proof of concept

1. Connect a `Mint.HTTP2` client with default `client_settings` to a server that writes raw HTTP/2 frames, and open a request. 2. Answer with a header block that stores one large `cookie` value in the HPACK dynamic table and then references it many times with indexed fields, keeping the compressed block under the 262,144-byte limit. 3. Mint accepts the block and returns one `cookie` header thousands of times larger than the wire bytes; the reporter measured a 1,047,808,858-byte value from 262,296 wire bytes on mint 1.10.1. 4. Answering several open requests in one delivery adds up: four responses held 4,240,710,592 bytes of cookie values at once. 5. A block of 60,000 references costs about 240 MB under the `cookie` field name and about 5 MB under a non-cookie name, which isolates `join_cookie_headers/1` as the amplifier.

## Impact

A malicious or compromised HTTP/2 server can make a Mint client allocate about 1 GB per response with default settings, exhausting host memory until the operating system kills the BEAM. HTTP/2 connection pools in Finch and Req, webhook and scraper clients, and reverse proxies fetching from untrusted upstreams are affected without any opt-in.

## Workarounds

Lower `client_settings: [max_header_list_size: n]` in `Mint.HTTP.connect/4`. The compressed check still applies, and each byte of the block can expand to at most one 4 KB table entry, so a limit of 4,096 bounds a response to roughly 16 MB. Alternatively, restrict connections to untrusted servers to HTTP/1 with `protocols: [:http1]`, which avoids the HTTP/2 receive path entirely. Do not set `max_header_list_size: :infinity`, which disables the compressed check as well.