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.