mint

Summary

Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') vulnerability in elixir-mint mint allows a malicious HTTP/1 server to desynchronize an intermediary and the Mint client on a pooled connection, poisoning the responses to subsequent requests that share the connection.

message_body/1 in lib/mint/http1.ex selects chunked framing when chunked is the first coding listed in a response's Transfer-Encoding fields. RFC 9112 section 6.3 applies chunked framing only when chunked is the final coding, and otherwise reads the body until the server closes the connection. For a response such as Transfer-Encoding: chunked, gzip, an intermediary that follows the RFC treats every byte up to the close as the body, while Mint ends the body at the zero-length chunk and parses the remaining bytes as the response to the next request on the connection.

Mint also keeps the connection open after an HTTP/1.0 response, final or 1xx, that carries Transfer-Encoding and Connection: keep-alive. RFC 9112 section 6.1 requires treating the framing of such a message as faulty and closing the connection after it, so bytes after its chunked body are parsed as the response to the next request in the same way.

This issue affects mint: from 0.1.0 before 1.10.2.

Details

1. Coding list. store_header/3 in lib/mint/http1.ex tokenizes each Transfer-Encoding field with Mint.HTTP1.Parse.transfer_encoding_header/1 and appends the codings to request.transfer_encoding in the order received.

2. Framing decision. message_body/1 returns chunked framing when List.first(request.transfer_encoding) is "chunked". The only other Transfer-Encoding check rejects a response that also carries Content-Length, so chunked, gzip on its own is framed as chunked.

3. Leftover bytes. decode_body/5 ends the body at the zero-length chunk and its trailer section, and next_request/3 keeps the rest of the data in conn.buffer or decodes it immediately as the next queued response. An RFC 9112 intermediary frames the same response as ending at connection close, so bytes it forwarded as body of the first response become the response to the next request on the Mint connection, and that request's real response is left in the buffer for the one after it.

4. HTTP/1.0 keep-alive. request_done/2 keeps an HTTP/1.0 connection open when the response has Connection: keep-alive, without checking for Transfer-Encoding, and decode_body(:informational, ...) resets the framing state of a 1xx response and keeps parsing. An HTTP/1.0 response with Transfer-Encoding: chunked and Connection: keep-alive therefore leaves the connection open after its chunked body, and the following bytes are decoded as the next queued response, although RFC 9112 section 6.1 requires closing the connection after such a message.

Proof of concept

1. Start a loopback TCP server that answers the first request with HTTP/1.1 200 OK and Transfer-Encoding: chunked, gzip, the chunked body 5\r\nLEGIT\r\n0\r\n\r\n, and directly after it the bytes HTTP/1.1 200 OK\r\nContent-Length: 8\r\n\r\nSMUGGLED.
2. Connect with Mint.HTTP1 and send a request. Mint returns LEGIT as the complete body, keeps the connection open, and holds the second response in conn.buffer.
3. Send a second request on the same connection and have the server answer it with a real response. Mint returns SMUGGLED as the response to the second request and keeps the real one in the buffer.
4. Pipelining both requests before the server answers gives the same result from a single Mint.HTTP1.stream/2 call.

Impact

A malicious or attacker-influenced HTTP/1 origin behind an intermediary that follows RFC 9112 framing can make the intermediary and the Mint client disagree on where a response ends. On a pooled keep-alive connection, bytes the origin appends to one response become the response to the next request sharing the connection, and the real responses shift to later requests.

Configurations

Exploitation requires an HTTP/1 intermediary (proxy, load balancer, or gateway) between the Mint client and the attacker-influenced origin that frames a response whose final transfer coding is not chunked as ending at connection close and forwards its Transfer-Encoding header to the client unchanged, and HTTP/1 connections between the client and the intermediary that are reused across requests. Intermediaries that reject such a header or re-frame the body do not create the disagreement. Mint clients that connect to the origin directly, or that don't reuse connections, aren't exposed to response-queue poisoning.

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.10.2.

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.

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.10.2.

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.

Summary

Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') vulnerability in elixir-mint mint allows a malicious HTTP/1 server to desynchronize an intermediary and the Mint client on a pooled connection, poisoning the responses to subsequent requests that share the connection.

message_body/1 in lib/mint/http1.ex selects chunked framing when chunked is the first coding listed in a response's Transfer-Encoding fields. RFC 9112 section 6.3 applies chunked framing only when chunked is the final coding, and otherwise reads the body until the server closes the connection. For a response such as Transfer-Encoding: chunked, gzip, an intermediary that follows the RFC treats every byte up to the close as the body, while Mint ends the body at the zero-length chunk and parses the remaining bytes as the response to the next request on the connection.

Mint also keeps the connection open after an HTTP/1.0 response, final or 1xx, that carries Transfer-Encoding and Connection: keep-alive. RFC 9112 section 6.1 requires treating the framing of such a message as faulty and closing the connection after it, so bytes after its chunked body are parsed as the response to the next request in the same way.

This issue affects mint: from 0.1.0 before 1.10.2.

Details

1. Coding list. store_header/3 in lib/mint/http1.ex tokenizes each Transfer-Encoding field with Mint.HTTP1.Parse.transfer_encoding_header/1 and appends the codings to request.transfer_encoding in the order received.

2. Framing decision. message_body/1 returns chunked framing when List.first(request.transfer_encoding) is "chunked". The only other Transfer-Encoding check rejects a response that also carries Content-Length, so chunked, gzip on its own is framed as chunked.

3. Leftover bytes. decode_body/5 ends the body at the zero-length chunk and its trailer section, and next_request/3 keeps the rest of the data in conn.buffer or decodes it immediately as the next queued response. An RFC 9112 intermediary frames the same response as ending at connection close, so bytes it forwarded as body of the first response become the response to the next request on the Mint connection, and that request's real response is left in the buffer for the one after it.

4. HTTP/1.0 keep-alive. request_done/2 keeps an HTTP/1.0 connection open when the response has Connection: keep-alive, without checking for Transfer-Encoding, and decode_body(:informational, ...) resets the framing state of a 1xx response and keeps parsing. An HTTP/1.0 response with Transfer-Encoding: chunked and Connection: keep-alive therefore leaves the connection open after its chunked body, and the following bytes are decoded as the next queued response, although RFC 9112 section 6.1 requires closing the connection after such a message.

Proof of concept

1. Start a loopback TCP server that answers the first request with HTTP/1.1 200 OK and Transfer-Encoding: chunked, gzip, the chunked body 5\r\nLEGIT\r\n0\r\n\r\n, and directly after it the bytes HTTP/1.1 200 OK\r\nContent-Length: 8\r\n\r\nSMUGGLED.
2. Connect with Mint.HTTP1 and send a request. Mint returns LEGIT as the complete body, keeps the connection open, and holds the second response in conn.buffer.
3. Send a second request on the same connection and have the server answer it with a real response. Mint returns SMUGGLED as the response to the second request and keeps the real one in the buffer.
4. Pipelining both requests before the server answers gives the same result from a single Mint.HTTP1.stream/2 call.

Impact

A malicious or attacker-influenced HTTP/1 origin behind an intermediary that follows RFC 9112 framing can make the intermediary and the Mint client disagree on where a response ends. On a pooled keep-alive connection, bytes the origin appends to one response become the response to the next request sharing the connection, and the real responses shift to later requests.

Configurations

Exploitation requires an HTTP/1 intermediary (proxy, load balancer, or gateway) between the Mint client and the attacker-influenced origin that frames a response whose final transfer coding is not chunked as ending at connection close and forwards its Transfer-Encoding header to the client unchanged, and HTTP/1 connections between the client and the intermediary that are reused across requests. Intermediaries that reject such a header or re-frame the body do not create the disagreement. Mint clients that connect to the origin directly, or that don't reuse connections, aren't exposed to response-queue poisoning.

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.10.2.

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.

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.10.2.

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.

Summary

Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') vulnerability in elixir-mint mint allows a malicious HTTP/1 server to desynchronize a strict intermediary and the Mint client on a pooled connection, enabling response-queue poisoning against subsequent requests that share the connection.

Mint.HTTP1.Parse.chunk_size/1 in lib/mint/http1/parse.ex stops at the first non-hexadecimal byte of a chunked response's chunk-size line and returns the remainder unexamined. Mint.HTTP1.decode_body/5 in lib/mint/http1.ex then discards every byte up to the CRLF with Parse.ignore_until_crlf/1, so the accepted grammar is a run of hex digits followed by arbitrary bytes, where RFC 9112 permits only a ;-introduced chunk extension. Lines such as 5ZZZZZ and 5 9 are accepted as chunk size 5, and 0ZZZZ is accepted as the terminating chunk that ends the message body. An RFC-strict intermediary rejects such a line while Mint accepts it, so the two disagree on chunk boundaries and on where the response ends.

This issue affects mint: from 0.1.0 before 1.10.1.

Details

1. Chunk-size parsing. Mint.HTTP1.Parse.chunk_size/1 in lib/mint/http1/parse.ex folds leading hexadecimal digits into an accumulator through parse_hex_prefix/3 and, on the first byte that is not a hex digit, returns {:ok, size, rest} with rest unexamined. The sign and digit-count checks added by earlier fixes constrain only the digits.

2. Tail skipping. The caller, Mint.HTTP1.decode_body/5 in lib/mint/http1.ex, hands rest to Parse.ignore_until_crlf/1, which advances over any byte until it finds CRLF. Nothing between the last hex digit and the CRLF is validated, so the accepted grammar is 1*HEXDIG *OCTET CRLF, where RFC 9112 section 7.1 allows only an optional ;-introduced chunk-ext. The same tolerance applies to the terminating zero-length chunk, which is the token that ends the message body.

3. Parser disagreement. The sibling Content-Length parser, Mint.HTTP1.Parse.content_length_header/1, trims trailing whitespace and requires the whole remaining value to be digits, rejecting anything else. An RFC-strict intermediary that rejects or reframes a chunk-size line with a non-extension tail, on a connection where Mint accepts it, yields a framing disagreement about chunk length and, through the terminating chunk, about where the message ends.

Proof of concept

1. Start a loopback TCP server that serves one HTTP/1.1 200 OK response with transfer-encoding: chunked and controls the chunk-size line byte for byte.
2. Connect with Mint.HTTP1 (mint 1.10.0 from Hex), send a request and stream the response.
3. Positive controls: chunk-size lines +5, Z5 and 00000000000000005 are refused with :invalid_chunk_size, confirming the build carries the earlier chunk-size fixes.
4. Baseline: 5 and 5;name=value are accepted with body hello.
5. Finding: 5ZZZZZ, 5 anything at all, 5<TAB>foo, 5 9 and 5}~! are each accepted as chunk size 5 with body hello.
6. Terminator: 0ZZZZ and 0 9 in place of the final 0 chunk are accepted and end the body.
7. Contrast: Content-Length: +5, Content-Length: 5ZZZ and Content-Length: 5 9 are refused with :invalid_content_length_header in the same run.

The reporter ran this on Elixir 1.18 / OTP 27 and Elixir 1.18.4 / OTP 28 with identical results.

Impact

A malicious or attacker-influenced HTTP/1 origin behind an RFC-strict intermediary can make the intermediary and the Mint client disagree on chunk boundaries and on where the response body ends. On a pooled keep-alive connection that disagreement lets bytes from one response be attributed to the next, poisoning the responses returned to unrelated requests that share the connection.

Configurations

Exploitation requires a deployment topology in which an RFC-strict HTTP/1 intermediary (proxy, load balancer, or WAF) sits between the Mint client and the attacker-influenced origin, and HTTP/1 connections between the client and the intermediary are reused across requests (keep-alive with connection pooling). Mint clients that talk directly to an origin without an intermediary, or that do not reuse connections, are not exploitable for response-queue poisoning even if the vulnerable parsing behavior is present.

Summary

Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') vulnerability in elixir-mint mint allows a malicious HTTP/1 server to desynchronize an intermediary and the Mint client on a pooled connection, poisoning the responses to subsequent requests that share the connection.

message_body/1 in lib/mint/http1.ex selects chunked framing when chunked is the first coding listed in a response's Transfer-Encoding fields. RFC 9112 section 6.3 applies chunked framing only when chunked is the final coding, and otherwise reads the body until the server closes the connection. For a response such as Transfer-Encoding: chunked, gzip, an intermediary that follows the RFC treats every byte up to the close as the body, while Mint ends the body at the zero-length chunk and parses the remaining bytes as the response to the next request on the connection.

Mint also keeps the connection open after an HTTP/1.0 response, final or 1xx, that carries Transfer-Encoding and Connection: keep-alive. RFC 9112 section 6.1 requires treating the framing of such a message as faulty and closing the connection after it, so bytes after its chunked body are parsed as the response to the next request in the same way.

This issue affects mint: from 0.1.0 before 1.10.2.

Details

1. Coding list. store_header/3 in lib/mint/http1.ex tokenizes each Transfer-Encoding field with Mint.HTTP1.Parse.transfer_encoding_header/1 and appends the codings to request.transfer_encoding in the order received.

2. Framing decision. message_body/1 returns chunked framing when List.first(request.transfer_encoding) is "chunked". The only other Transfer-Encoding check rejects a response that also carries Content-Length, so chunked, gzip on its own is framed as chunked.

3. Leftover bytes. decode_body/5 ends the body at the zero-length chunk and its trailer section, and next_request/3 keeps the rest of the data in conn.buffer or decodes it immediately as the next queued response. An RFC 9112 intermediary frames the same response as ending at connection close, so bytes it forwarded as body of the first response become the response to the next request on the Mint connection, and that request's real response is left in the buffer for the one after it.

4. HTTP/1.0 keep-alive. request_done/2 keeps an HTTP/1.0 connection open when the response has Connection: keep-alive, without checking for Transfer-Encoding, and decode_body(:informational, ...) resets the framing state of a 1xx response and keeps parsing. An HTTP/1.0 response with Transfer-Encoding: chunked and Connection: keep-alive therefore leaves the connection open after its chunked body, and the following bytes are decoded as the next queued response, although RFC 9112 section 6.1 requires closing the connection after such a message.

Proof of concept

1. Start a loopback TCP server that answers the first request with HTTP/1.1 200 OK and Transfer-Encoding: chunked, gzip, the chunked body 5\r\nLEGIT\r\n0\r\n\r\n, and directly after it the bytes HTTP/1.1 200 OK\r\nContent-Length: 8\r\n\r\nSMUGGLED.
2. Connect with Mint.HTTP1 and send a request. Mint returns LEGIT as the complete body, keeps the connection open, and holds the second response in conn.buffer.
3. Send a second request on the same connection and have the server answer it with a real response. Mint returns SMUGGLED as the response to the second request and keeps the real one in the buffer.
4. Pipelining both requests before the server answers gives the same result from a single Mint.HTTP1.stream/2 call.

Impact

A malicious or attacker-influenced HTTP/1 origin behind an intermediary that follows RFC 9112 framing can make the intermediary and the Mint client disagree on where a response ends. On a pooled keep-alive connection, bytes the origin appends to one response become the response to the next request sharing the connection, and the real responses shift to later requests.

Configurations

Exploitation requires an HTTP/1 intermediary (proxy, load balancer, or gateway) between the Mint client and the attacker-influenced origin that frames a response whose final transfer coding is not chunked as ending at connection close and forwards its Transfer-Encoding header to the client unchanged, and HTTP/1 connections between the client and the intermediary that are reused across requests. Intermediaries that reject such a header or re-frame the body do not create the disagreement. Mint clients that connect to the origin directly, or that don't reuse connections, aren't exposed to response-queue poisoning.

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.10.2.

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.

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.10.2.

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.

Summary

Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') vulnerability in elixir-mint mint allows a malicious HTTP/1 server to desynchronize a strict intermediary and the Mint client on a pooled connection, enabling response-queue poisoning against subsequent requests that share the connection.

Mint.HTTP1.Parse.chunk_size/1 in lib/mint/http1/parse.ex stops at the first non-hexadecimal byte of a chunked response's chunk-size line and returns the remainder unexamined. Mint.HTTP1.decode_body/5 in lib/mint/http1.ex then discards every byte up to the CRLF with Parse.ignore_until_crlf/1, so the accepted grammar is a run of hex digits followed by arbitrary bytes, where RFC 9112 permits only a ;-introduced chunk extension. Lines such as 5ZZZZZ and 5 9 are accepted as chunk size 5, and 0ZZZZ is accepted as the terminating chunk that ends the message body. An RFC-strict intermediary rejects such a line while Mint accepts it, so the two disagree on chunk boundaries and on where the response ends.

This issue affects mint: from 0.1.0 before 1.10.1.

Details

1. Chunk-size parsing. Mint.HTTP1.Parse.chunk_size/1 in lib/mint/http1/parse.ex folds leading hexadecimal digits into an accumulator through parse_hex_prefix/3 and, on the first byte that is not a hex digit, returns {:ok, size, rest} with rest unexamined. The sign and digit-count checks added by earlier fixes constrain only the digits.

2. Tail skipping. The caller, Mint.HTTP1.decode_body/5 in lib/mint/http1.ex, hands rest to Parse.ignore_until_crlf/1, which advances over any byte until it finds CRLF. Nothing between the last hex digit and the CRLF is validated, so the accepted grammar is 1*HEXDIG *OCTET CRLF, where RFC 9112 section 7.1 allows only an optional ;-introduced chunk-ext. The same tolerance applies to the terminating zero-length chunk, which is the token that ends the message body.

3. Parser disagreement. The sibling Content-Length parser, Mint.HTTP1.Parse.content_length_header/1, trims trailing whitespace and requires the whole remaining value to be digits, rejecting anything else. An RFC-strict intermediary that rejects or reframes a chunk-size line with a non-extension tail, on a connection where Mint accepts it, yields a framing disagreement about chunk length and, through the terminating chunk, about where the message ends.

Proof of concept

1. Start a loopback TCP server that serves one HTTP/1.1 200 OK response with transfer-encoding: chunked and controls the chunk-size line byte for byte.
2. Connect with Mint.HTTP1 (mint 1.10.0 from Hex), send a request and stream the response.
3. Positive controls: chunk-size lines +5, Z5 and 00000000000000005 are refused with :invalid_chunk_size, confirming the build carries the earlier chunk-size fixes.
4. Baseline: 5 and 5;name=value are accepted with body hello.
5. Finding: 5ZZZZZ, 5 anything at all, 5<TAB>foo, 5 9 and 5}~! are each accepted as chunk size 5 with body hello.
6. Terminator: 0ZZZZ and 0 9 in place of the final 0 chunk are accepted and end the body.
7. Contrast: Content-Length: +5, Content-Length: 5ZZZ and Content-Length: 5 9 are refused with :invalid_content_length_header in the same run.

The reporter ran this on Elixir 1.18 / OTP 27 and Elixir 1.18.4 / OTP 28 with identical results.

Impact

A malicious or attacker-influenced HTTP/1 origin behind an RFC-strict intermediary can make the intermediary and the Mint client disagree on chunk boundaries and on where the response body ends. On a pooled keep-alive connection that disagreement lets bytes from one response be attributed to the next, poisoning the responses returned to unrelated requests that share the connection.

Configurations

Exploitation requires a deployment topology in which an RFC-strict HTTP/1 intermediary (proxy, load balancer, or WAF) sits between the Mint client and the attacker-influenced origin, and HTTP/1 connections between the client and the intermediary are reused across requests (keep-alive with connection pooling). Mint clients that talk directly to an origin without an intermediary, or that do not reuse connections, are not exploitable for response-queue poisoning even if the vulnerable parsing behavior is present.

Summary

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

Two HTTP/1 response-parser states accumulate server data without any cap. In lib/mint/http1.ex, decode_status_line/4 stores the unconsumed data in conn.buffer when the status line is incomplete, and decode_body/5 does the same for an unterminated chunk-extension line. Both wait for a CRLF the server never has to send, and conn.buffer is prepended to every subsequent socket message. The :max_header_list_size budget is wired only into decode_headers/5 and decode_trailer_headers/4, so neither of these states is covered by it. A malicious server, or one reached through an attacker-controlled redirect or a fetched URL, streams bytes indefinitely until the BEAM node is killed by the operating system out-of-memory handler. The chunk-extension variant is reached after a valid status line and a complete, valid header section, so an intermediary inspecting only headers sees an ordinary 200 response.

This issue affects mint: from 0.1.0 before 1.10.0.

Summary

Inefficient Algorithmic Complexity vulnerability in elixir-mint mint allows a remote HTTP server to exhaust CPU on the client host and cause a denial of service.

parse_hex_prefix/2 in lib/mint/http1/parse.ex folds each hex digit of a chunked response's chunk-size field into an arbitrary-precision accumulator with acc * 16 + digit and imposes no limit on the digit count. Because the accumulator grows without bound, the multiplication is not constant time and one pass over N digits costs O(N squared). handle_data/2 prepends conn.buffer and re-parses from the start on every socket message, so a server that dribbles the digits out in small packets makes the client pay that cost repeatedly. A run of roughly 512,000 hex digits costs over ten seconds of CPU in a single pass, measured on stock defaults. The parser reaches this state after a valid status line and a complete, valid header section, so an intermediary inspecting only headers sees an ordinary 200 response.

This issue affects mint: from 1.9.3 before 1.10.0.

Summary

Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') vulnerability in elixir-mint mint allows a malicious HTTP/1 server to desynchronize an intermediary and the Mint client on a pooled connection, poisoning the responses to subsequent requests that share the connection.

message_body/1 in lib/mint/http1.ex selects chunked framing when chunked is the first coding listed in a response's Transfer-Encoding fields. RFC 9112 section 6.3 applies chunked framing only when chunked is the final coding, and otherwise reads the body until the server closes the connection. For a response such as Transfer-Encoding: chunked, gzip, an intermediary that follows the RFC treats every byte up to the close as the body, while Mint ends the body at the zero-length chunk and parses the remaining bytes as the response to the next request on the connection.

Mint also keeps the connection open after an HTTP/1.0 response, final or 1xx, that carries Transfer-Encoding and Connection: keep-alive. RFC 9112 section 6.1 requires treating the framing of such a message as faulty and closing the connection after it, so bytes after its chunked body are parsed as the response to the next request in the same way.

This issue affects mint: from 0.1.0 before 1.10.2.

Details

1. Coding list. store_header/3 in lib/mint/http1.ex tokenizes each Transfer-Encoding field with Mint.HTTP1.Parse.transfer_encoding_header/1 and appends the codings to request.transfer_encoding in the order received.

2. Framing decision. message_body/1 returns chunked framing when List.first(request.transfer_encoding) is "chunked". The only other Transfer-Encoding check rejects a response that also carries Content-Length, so chunked, gzip on its own is framed as chunked.

3. Leftover bytes. decode_body/5 ends the body at the zero-length chunk and its trailer section, and next_request/3 keeps the rest of the data in conn.buffer or decodes it immediately as the next queued response. An RFC 9112 intermediary frames the same response as ending at connection close, so bytes it forwarded as body of the first response become the response to the next request on the Mint connection, and that request's real response is left in the buffer for the one after it.

4. HTTP/1.0 keep-alive. request_done/2 keeps an HTTP/1.0 connection open when the response has Connection: keep-alive, without checking for Transfer-Encoding, and decode_body(:informational, ...) resets the framing state of a 1xx response and keeps parsing. An HTTP/1.0 response with Transfer-Encoding: chunked and Connection: keep-alive therefore leaves the connection open after its chunked body, and the following bytes are decoded as the next queued response, although RFC 9112 section 6.1 requires closing the connection after such a message.

Proof of concept

1. Start a loopback TCP server that answers the first request with HTTP/1.1 200 OK and Transfer-Encoding: chunked, gzip, the chunked body 5\r\nLEGIT\r\n0\r\n\r\n, and directly after it the bytes HTTP/1.1 200 OK\r\nContent-Length: 8\r\n\r\nSMUGGLED.
2. Connect with Mint.HTTP1 and send a request. Mint returns LEGIT as the complete body, keeps the connection open, and holds the second response in conn.buffer.
3. Send a second request on the same connection and have the server answer it with a real response. Mint returns SMUGGLED as the response to the second request and keeps the real one in the buffer.
4. Pipelining both requests before the server answers gives the same result from a single Mint.HTTP1.stream/2 call.

Impact

A malicious or attacker-influenced HTTP/1 origin behind an intermediary that follows RFC 9112 framing can make the intermediary and the Mint client disagree on where a response ends. On a pooled keep-alive connection, bytes the origin appends to one response become the response to the next request sharing the connection, and the real responses shift to later requests.

Configurations

Exploitation requires an HTTP/1 intermediary (proxy, load balancer, or gateway) between the Mint client and the attacker-influenced origin that frames a response whose final transfer coding is not chunked as ending at connection close and forwards its Transfer-Encoding header to the client unchanged, and HTTP/1 connections between the client and the intermediary that are reused across requests. Intermediaries that reject such a header or re-frame the body do not create the disagreement. Mint clients that connect to the origin directly, or that don't reuse connections, aren't exposed to response-queue poisoning.

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.10.2.

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.

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.10.2.

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.

Summary

Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') vulnerability in elixir-mint mint allows a malicious HTTP/1 server to desynchronize a strict intermediary and the Mint client on a pooled connection, enabling response-queue poisoning against subsequent requests that share the connection.

Mint.HTTP1.Parse.chunk_size/1 in lib/mint/http1/parse.ex stops at the first non-hexadecimal byte of a chunked response's chunk-size line and returns the remainder unexamined. Mint.HTTP1.decode_body/5 in lib/mint/http1.ex then discards every byte up to the CRLF with Parse.ignore_until_crlf/1, so the accepted grammar is a run of hex digits followed by arbitrary bytes, where RFC 9112 permits only a ;-introduced chunk extension. Lines such as 5ZZZZZ and 5 9 are accepted as chunk size 5, and 0ZZZZ is accepted as the terminating chunk that ends the message body. An RFC-strict intermediary rejects such a line while Mint accepts it, so the two disagree on chunk boundaries and on where the response ends.

This issue affects mint: from 0.1.0 before 1.10.1.

Details

1. Chunk-size parsing. Mint.HTTP1.Parse.chunk_size/1 in lib/mint/http1/parse.ex folds leading hexadecimal digits into an accumulator through parse_hex_prefix/3 and, on the first byte that is not a hex digit, returns {:ok, size, rest} with rest unexamined. The sign and digit-count checks added by earlier fixes constrain only the digits.

2. Tail skipping. The caller, Mint.HTTP1.decode_body/5 in lib/mint/http1.ex, hands rest to Parse.ignore_until_crlf/1, which advances over any byte until it finds CRLF. Nothing between the last hex digit and the CRLF is validated, so the accepted grammar is 1*HEXDIG *OCTET CRLF, where RFC 9112 section 7.1 allows only an optional ;-introduced chunk-ext. The same tolerance applies to the terminating zero-length chunk, which is the token that ends the message body.

3. Parser disagreement. The sibling Content-Length parser, Mint.HTTP1.Parse.content_length_header/1, trims trailing whitespace and requires the whole remaining value to be digits, rejecting anything else. An RFC-strict intermediary that rejects or reframes a chunk-size line with a non-extension tail, on a connection where Mint accepts it, yields a framing disagreement about chunk length and, through the terminating chunk, about where the message ends.

Proof of concept

1. Start a loopback TCP server that serves one HTTP/1.1 200 OK response with transfer-encoding: chunked and controls the chunk-size line byte for byte.
2. Connect with Mint.HTTP1 (mint 1.10.0 from Hex), send a request and stream the response.
3. Positive controls: chunk-size lines +5, Z5 and 00000000000000005 are refused with :invalid_chunk_size, confirming the build carries the earlier chunk-size fixes.
4. Baseline: 5 and 5;name=value are accepted with body hello.
5. Finding: 5ZZZZZ, 5 anything at all, 5<TAB>foo, 5 9 and 5}~! are each accepted as chunk size 5 with body hello.
6. Terminator: 0ZZZZ and 0 9 in place of the final 0 chunk are accepted and end the body.
7. Contrast: Content-Length: +5, Content-Length: 5ZZZ and Content-Length: 5 9 are refused with :invalid_content_length_header in the same run.

The reporter ran this on Elixir 1.18 / OTP 27 and Elixir 1.18.4 / OTP 28 with identical results.

Impact

A malicious or attacker-influenced HTTP/1 origin behind an RFC-strict intermediary can make the intermediary and the Mint client disagree on chunk boundaries and on where the response body ends. On a pooled keep-alive connection that disagreement lets bytes from one response be attributed to the next, poisoning the responses returned to unrelated requests that share the connection.

Configurations

Exploitation requires a deployment topology in which an RFC-strict HTTP/1 intermediary (proxy, load balancer, or WAF) sits between the Mint client and the attacker-influenced origin, and HTTP/1 connections between the client and the intermediary are reused across requests (keep-alive with connection pooling). Mint clients that talk directly to an origin without an intermediary, or that do not reuse connections, are not exploitable for response-queue poisoning even if the vulnerable parsing behavior is present.

Summary

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

Two HTTP/1 response-parser states accumulate server data without any cap. In lib/mint/http1.ex, decode_status_line/4 stores the unconsumed data in conn.buffer when the status line is incomplete, and decode_body/5 does the same for an unterminated chunk-extension line. Both wait for a CRLF the server never has to send, and conn.buffer is prepended to every subsequent socket message. The :max_header_list_size budget is wired only into decode_headers/5 and decode_trailer_headers/4, so neither of these states is covered by it. A malicious server, or one reached through an attacker-controlled redirect or a fetched URL, streams bytes indefinitely until the BEAM node is killed by the operating system out-of-memory handler. The chunk-extension variant is reached after a valid status line and a complete, valid header section, so an intermediary inspecting only headers sees an ordinary 200 response.

This issue affects mint: from 0.1.0 before 1.10.0.

Summary

Inconsistent interpretation of HTTP requests (HTTP response smuggling) vulnerability in elixir-mint mint allows a malicious HTTP/1 server to desynchronize a strict intermediary and the Mint client on the same pooled connection, enabling response-queue poisoning against subsequent requests that share the connection.

The Mint.HTTP1.decode_body/5 function in lib/mint/http1.ex parses the chunk-size line of a Transfer-Encoding: chunked response with Integer.parse(data, 16). RFC 7230 defines chunk-size = 1*HEXDIG and forbids any sign prefix, but Integer.parse/2 accepts an optional leading + or -. A chunk-size line of +5 is accepted as a five-byte chunk; lines of +0 and -0 are accepted as the terminating zero-length chunk and end the message body early.

An RFC-strict intermediary in the response path rejects these forms, so the intermediary and the Mint client disagree on where one response ends and the next begins. On a pooled keep-alive connection, an attacker-influenced origin can inject bytes that the client attributes to the next legitimate response on the same connection, poisoning the response queue and corrupting the responses returned to unrelated in-flight requests.

This issue affects mint: from 0.1.0 before 1.9.3.

Configurations

Exploitation requires a deployment topology in which an RFC-strict HTTP/1 intermediary (proxy, load balancer, or WAF) sits between the Mint client and the attacker-influenced origin, and HTTP/1 connections between the client and the intermediary are reused across requests (keep-alive with connection pooling). Mint clients that talk directly to an origin without an intermediary, or that do not reuse connections, are not exploitable for response-queue poisoning even if the vulnerable parsing behavior is present.

Summary

Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') vulnerability in elixir-mint mint allows a malicious HTTP/1 server to desynchronize an intermediary and the Mint client on a pooled connection, poisoning the responses to subsequent requests that share the connection.

message_body/1 in lib/mint/http1.ex selects chunked framing when chunked is the first coding listed in a response's Transfer-Encoding fields. RFC 9112 section 6.3 applies chunked framing only when chunked is the final coding, and otherwise reads the body until the server closes the connection. For a response such as Transfer-Encoding: chunked, gzip, an intermediary that follows the RFC treats every byte up to the close as the body, while Mint ends the body at the zero-length chunk and parses the remaining bytes as the response to the next request on the connection.

Mint also keeps the connection open after an HTTP/1.0 response, final or 1xx, that carries Transfer-Encoding and Connection: keep-alive. RFC 9112 section 6.1 requires treating the framing of such a message as faulty and closing the connection after it, so bytes after its chunked body are parsed as the response to the next request in the same way.

This issue affects mint: from 0.1.0 before 1.10.2.

Details

1. Coding list. store_header/3 in lib/mint/http1.ex tokenizes each Transfer-Encoding field with Mint.HTTP1.Parse.transfer_encoding_header/1 and appends the codings to request.transfer_encoding in the order received.

2. Framing decision. message_body/1 returns chunked framing when List.first(request.transfer_encoding) is "chunked". The only other Transfer-Encoding check rejects a response that also carries Content-Length, so chunked, gzip on its own is framed as chunked.

3. Leftover bytes. decode_body/5 ends the body at the zero-length chunk and its trailer section, and next_request/3 keeps the rest of the data in conn.buffer or decodes it immediately as the next queued response. An RFC 9112 intermediary frames the same response as ending at connection close, so bytes it forwarded as body of the first response become the response to the next request on the Mint connection, and that request's real response is left in the buffer for the one after it.

4. HTTP/1.0 keep-alive. request_done/2 keeps an HTTP/1.0 connection open when the response has Connection: keep-alive, without checking for Transfer-Encoding, and decode_body(:informational, ...) resets the framing state of a 1xx response and keeps parsing. An HTTP/1.0 response with Transfer-Encoding: chunked and Connection: keep-alive therefore leaves the connection open after its chunked body, and the following bytes are decoded as the next queued response, although RFC 9112 section 6.1 requires closing the connection after such a message.

Proof of concept

1. Start a loopback TCP server that answers the first request with HTTP/1.1 200 OK and Transfer-Encoding: chunked, gzip, the chunked body 5\r\nLEGIT\r\n0\r\n\r\n, and directly after it the bytes HTTP/1.1 200 OK\r\nContent-Length: 8\r\n\r\nSMUGGLED.
2. Connect with Mint.HTTP1 and send a request. Mint returns LEGIT as the complete body, keeps the connection open, and holds the second response in conn.buffer.
3. Send a second request on the same connection and have the server answer it with a real response. Mint returns SMUGGLED as the response to the second request and keeps the real one in the buffer.
4. Pipelining both requests before the server answers gives the same result from a single Mint.HTTP1.stream/2 call.

Impact

A malicious or attacker-influenced HTTP/1 origin behind an intermediary that follows RFC 9112 framing can make the intermediary and the Mint client disagree on where a response ends. On a pooled keep-alive connection, bytes the origin appends to one response become the response to the next request sharing the connection, and the real responses shift to later requests.

Configurations

Exploitation requires an HTTP/1 intermediary (proxy, load balancer, or gateway) between the Mint client and the attacker-influenced origin that frames a response whose final transfer coding is not chunked as ending at connection close and forwards its Transfer-Encoding header to the client unchanged, and HTTP/1 connections between the client and the intermediary that are reused across requests. Intermediaries that reject such a header or re-frame the body do not create the disagreement. Mint clients that connect to the origin directly, or that don't reuse connections, aren't exposed to response-queue poisoning.

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.10.2.

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.

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.10.2.

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.

Summary

Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') vulnerability in elixir-mint mint allows a malicious HTTP/1 server to desynchronize a strict intermediary and the Mint client on a pooled connection, enabling response-queue poisoning against subsequent requests that share the connection.

Mint.HTTP1.Parse.chunk_size/1 in lib/mint/http1/parse.ex stops at the first non-hexadecimal byte of a chunked response's chunk-size line and returns the remainder unexamined. Mint.HTTP1.decode_body/5 in lib/mint/http1.ex then discards every byte up to the CRLF with Parse.ignore_until_crlf/1, so the accepted grammar is a run of hex digits followed by arbitrary bytes, where RFC 9112 permits only a ;-introduced chunk extension. Lines such as 5ZZZZZ and 5 9 are accepted as chunk size 5, and 0ZZZZ is accepted as the terminating chunk that ends the message body. An RFC-strict intermediary rejects such a line while Mint accepts it, so the two disagree on chunk boundaries and on where the response ends.

This issue affects mint: from 0.1.0 before 1.10.1.

Details

1. Chunk-size parsing. Mint.HTTP1.Parse.chunk_size/1 in lib/mint/http1/parse.ex folds leading hexadecimal digits into an accumulator through parse_hex_prefix/3 and, on the first byte that is not a hex digit, returns {:ok, size, rest} with rest unexamined. The sign and digit-count checks added by earlier fixes constrain only the digits.

2. Tail skipping. The caller, Mint.HTTP1.decode_body/5 in lib/mint/http1.ex, hands rest to Parse.ignore_until_crlf/1, which advances over any byte until it finds CRLF. Nothing between the last hex digit and the CRLF is validated, so the accepted grammar is 1*HEXDIG *OCTET CRLF, where RFC 9112 section 7.1 allows only an optional ;-introduced chunk-ext. The same tolerance applies to the terminating zero-length chunk, which is the token that ends the message body.

3. Parser disagreement. The sibling Content-Length parser, Mint.HTTP1.Parse.content_length_header/1, trims trailing whitespace and requires the whole remaining value to be digits, rejecting anything else. An RFC-strict intermediary that rejects or reframes a chunk-size line with a non-extension tail, on a connection where Mint accepts it, yields a framing disagreement about chunk length and, through the terminating chunk, about where the message ends.

Proof of concept

1. Start a loopback TCP server that serves one HTTP/1.1 200 OK response with transfer-encoding: chunked and controls the chunk-size line byte for byte.
2. Connect with Mint.HTTP1 (mint 1.10.0 from Hex), send a request and stream the response.
3. Positive controls: chunk-size lines +5, Z5 and 00000000000000005 are refused with :invalid_chunk_size, confirming the build carries the earlier chunk-size fixes.
4. Baseline: 5 and 5;name=value are accepted with body hello.
5. Finding: 5ZZZZZ, 5 anything at all, 5<TAB>foo, 5 9 and 5}~! are each accepted as chunk size 5 with body hello.
6. Terminator: 0ZZZZ and 0 9 in place of the final 0 chunk are accepted and end the body.
7. Contrast: Content-Length: +5, Content-Length: 5ZZZ and Content-Length: 5 9 are refused with :invalid_content_length_header in the same run.

The reporter ran this on Elixir 1.18 / OTP 27 and Elixir 1.18.4 / OTP 28 with identical results.

Impact

A malicious or attacker-influenced HTTP/1 origin behind an RFC-strict intermediary can make the intermediary and the Mint client disagree on chunk boundaries and on where the response body ends. On a pooled keep-alive connection that disagreement lets bytes from one response be attributed to the next, poisoning the responses returned to unrelated requests that share the connection.

Configurations

Exploitation requires a deployment topology in which an RFC-strict HTTP/1 intermediary (proxy, load balancer, or WAF) sits between the Mint client and the attacker-influenced origin, and HTTP/1 connections between the client and the intermediary are reused across requests (keep-alive with connection pooling). Mint clients that talk directly to an origin without an intermediary, or that do not reuse connections, are not exploitable for response-queue poisoning even if the vulnerable parsing behavior is present.

Summary

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

Two HTTP/1 response-parser states accumulate server data without any cap. In lib/mint/http1.ex, decode_status_line/4 stores the unconsumed data in conn.buffer when the status line is incomplete, and decode_body/5 does the same for an unterminated chunk-extension line. Both wait for a CRLF the server never has to send, and conn.buffer is prepended to every subsequent socket message. The :max_header_list_size budget is wired only into decode_headers/5 and decode_trailer_headers/4, so neither of these states is covered by it. A malicious server, or one reached through an attacker-controlled redirect or a fetched URL, streams bytes indefinitely until the BEAM node is killed by the operating system out-of-memory handler. The chunk-extension variant is reached after a valid status line and a complete, valid header section, so an intermediary inspecting only headers sees an ordinary 200 response.

This issue affects mint: from 0.1.0 before 1.10.0.

Summary

Inconsistent interpretation of HTTP requests (HTTP response smuggling) vulnerability in elixir-mint mint allows a malicious HTTP/1 server to desynchronize a strict intermediary and the Mint client on the same pooled connection, enabling response-queue poisoning against subsequent requests that share the connection.

The Mint.HTTP1.decode_body/5 function in lib/mint/http1.ex parses the chunk-size line of a Transfer-Encoding: chunked response with Integer.parse(data, 16). RFC 7230 defines chunk-size = 1*HEXDIG and forbids any sign prefix, but Integer.parse/2 accepts an optional leading + or -. A chunk-size line of +5 is accepted as a five-byte chunk; lines of +0 and -0 are accepted as the terminating zero-length chunk and end the message body early.

An RFC-strict intermediary in the response path rejects these forms, so the intermediary and the Mint client disagree on where one response ends and the next begins. On a pooled keep-alive connection, an attacker-influenced origin can inject bytes that the client attributes to the next legitimate response on the same connection, poisoning the response queue and corrupting the responses returned to unrelated in-flight requests.

This issue affects mint: from 0.1.0 before 1.9.3.

Configurations

Exploitation requires a deployment topology in which an RFC-strict HTTP/1 intermediary (proxy, load balancer, or WAF) sits between the Mint client and the attacker-influenced origin, and HTTP/1 connections between the client and the intermediary are reused across requests (keep-alive with connection pooling). Mint clients that talk directly to an origin without an intermediary, or that do not reuse connections, are not exploitable for response-queue poisoning even if the vulnerable parsing behavior is present.

Summary

Allocation of resources without limits vulnerability in elixir-mint mint allows a remote HTTP/2 server to exhaust memory on the client host and cause a denial of service.

The Mint.HTTP2.handle_continuation/3 function in lib/mint/http2.ex accumulates the header-block fragment carried by each HTTP/2 CONTINUATION frame into a growing conn.headers_being_processed nesting, one level deeper per frame, and only releases it when a frame with the END_HEADERS flag arrives. The only guard on this accumulator is Mint.HTTP2.assert_header_block_within_max_size/2, which sums the byte size of the fragments received so far. Because a CONTINUATION frame is permitted by the protocol to carry a zero-length payload, an unbounded chain of zero-length CONTINUATION frames adds no bytes to the running total, never trips the size cap, and never emits END_HEADERS, yet each frame still nests the accumulator one level deeper.

A malicious HTTP/2 server (reachable directly, via an attacker-controlled redirect, via SSRF, or via a man-in-the-middle) can open a stream by sending a HEADERS frame without END_HEADERS and then stream zero-length CONTINUATION frames indefinitely. Client memory grows one cons cell per frame received; sustained bandwidth from the peer drives the BEAM node running the Mint client to memory exhaustion and eventual out-of-memory termination.

This issue affects mint: from 0.1.0 before 1.9.2.

Summary

Allocation of resources without limits vulnerability in elixir-mint mint allows a remote HTTP server to exhaust memory on the client host and cause a denial of service.

The Mint.HTTP1.decode_headers/5 and Mint.HTTP1.decode_trailer_headers/4 functions in lib/mint/http1.ex accumulate every parsed response header and chunked-trailer field into a per-request list that persists across incoming TCP segments as request.headers_buffer, and only clear it when the terminating blank line is received. The section has no cap on the number of headers or on total bytes, and the underlying :erlang.decode_packet(:httph_bin, binary, []) parser is invoked with an empty option list so its per-line and per-packet size limits also default to unlimited.

A malicious HTTP server (reachable directly, via an attacker-controlled redirect, via SSRF, or via a man-in-the-middle) can stream complete header lines (or, after a chunked body, complete trailer lines) indefinitely without ever emitting the terminating blank line. The connection state grows without bound until the BEAM node is killed by the operating system's out-of-memory handler, taking down the entire application that uses Mint as an HTTP client.

This issue affects mint: from 0.1.0 before 1.9.2.

Summary

Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') vulnerability in elixir-mint mint allows a malicious HTTP/1 server to desynchronize an intermediary and the Mint client on a pooled connection, poisoning the responses to subsequent requests that share the connection.

message_body/1 in lib/mint/http1.ex selects chunked framing when chunked is the first coding listed in a response's Transfer-Encoding fields. RFC 9112 section 6.3 applies chunked framing only when chunked is the final coding, and otherwise reads the body until the server closes the connection. For a response such as Transfer-Encoding: chunked, gzip, an intermediary that follows the RFC treats every byte up to the close as the body, while Mint ends the body at the zero-length chunk and parses the remaining bytes as the response to the next request on the connection.

Mint also keeps the connection open after an HTTP/1.0 response, final or 1xx, that carries Transfer-Encoding and Connection: keep-alive. RFC 9112 section 6.1 requires treating the framing of such a message as faulty and closing the connection after it, so bytes after its chunked body are parsed as the response to the next request in the same way.

This issue affects mint: from 0.1.0 before 1.10.2.

Details

1. Coding list. store_header/3 in lib/mint/http1.ex tokenizes each Transfer-Encoding field with Mint.HTTP1.Parse.transfer_encoding_header/1 and appends the codings to request.transfer_encoding in the order received.

2. Framing decision. message_body/1 returns chunked framing when List.first(request.transfer_encoding) is "chunked". The only other Transfer-Encoding check rejects a response that also carries Content-Length, so chunked, gzip on its own is framed as chunked.

3. Leftover bytes. decode_body/5 ends the body at the zero-length chunk and its trailer section, and next_request/3 keeps the rest of the data in conn.buffer or decodes it immediately as the next queued response. An RFC 9112 intermediary frames the same response as ending at connection close, so bytes it forwarded as body of the first response become the response to the next request on the Mint connection, and that request's real response is left in the buffer for the one after it.

4. HTTP/1.0 keep-alive. request_done/2 keeps an HTTP/1.0 connection open when the response has Connection: keep-alive, without checking for Transfer-Encoding, and decode_body(:informational, ...) resets the framing state of a 1xx response and keeps parsing. An HTTP/1.0 response with Transfer-Encoding: chunked and Connection: keep-alive therefore leaves the connection open after its chunked body, and the following bytes are decoded as the next queued response, although RFC 9112 section 6.1 requires closing the connection after such a message.

Proof of concept

1. Start a loopback TCP server that answers the first request with HTTP/1.1 200 OK and Transfer-Encoding: chunked, gzip, the chunked body 5\r\nLEGIT\r\n0\r\n\r\n, and directly after it the bytes HTTP/1.1 200 OK\r\nContent-Length: 8\r\n\r\nSMUGGLED.
2. Connect with Mint.HTTP1 and send a request. Mint returns LEGIT as the complete body, keeps the connection open, and holds the second response in conn.buffer.
3. Send a second request on the same connection and have the server answer it with a real response. Mint returns SMUGGLED as the response to the second request and keeps the real one in the buffer.
4. Pipelining both requests before the server answers gives the same result from a single Mint.HTTP1.stream/2 call.

Impact

A malicious or attacker-influenced HTTP/1 origin behind an intermediary that follows RFC 9112 framing can make the intermediary and the Mint client disagree on where a response ends. On a pooled keep-alive connection, bytes the origin appends to one response become the response to the next request sharing the connection, and the real responses shift to later requests.

Configurations

Exploitation requires an HTTP/1 intermediary (proxy, load balancer, or gateway) between the Mint client and the attacker-influenced origin that frames a response whose final transfer coding is not chunked as ending at connection close and forwards its Transfer-Encoding header to the client unchanged, and HTTP/1 connections between the client and the intermediary that are reused across requests. Intermediaries that reject such a header or re-frame the body do not create the disagreement. Mint clients that connect to the origin directly, or that don't reuse connections, aren't exposed to response-queue poisoning.

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.10.2.

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.

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.10.2.

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.

Summary

Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') vulnerability in elixir-mint mint allows a malicious HTTP/1 server to desynchronize a strict intermediary and the Mint client on a pooled connection, enabling response-queue poisoning against subsequent requests that share the connection.

Mint.HTTP1.Parse.chunk_size/1 in lib/mint/http1/parse.ex stops at the first non-hexadecimal byte of a chunked response's chunk-size line and returns the remainder unexamined. Mint.HTTP1.decode_body/5 in lib/mint/http1.ex then discards every byte up to the CRLF with Parse.ignore_until_crlf/1, so the accepted grammar is a run of hex digits followed by arbitrary bytes, where RFC 9112 permits only a ;-introduced chunk extension. Lines such as 5ZZZZZ and 5 9 are accepted as chunk size 5, and 0ZZZZ is accepted as the terminating chunk that ends the message body. An RFC-strict intermediary rejects such a line while Mint accepts it, so the two disagree on chunk boundaries and on where the response ends.

This issue affects mint: from 0.1.0 before 1.10.1.

Details

1. Chunk-size parsing. Mint.HTTP1.Parse.chunk_size/1 in lib/mint/http1/parse.ex folds leading hexadecimal digits into an accumulator through parse_hex_prefix/3 and, on the first byte that is not a hex digit, returns {:ok, size, rest} with rest unexamined. The sign and digit-count checks added by earlier fixes constrain only the digits.

2. Tail skipping. The caller, Mint.HTTP1.decode_body/5 in lib/mint/http1.ex, hands rest to Parse.ignore_until_crlf/1, which advances over any byte until it finds CRLF. Nothing between the last hex digit and the CRLF is validated, so the accepted grammar is 1*HEXDIG *OCTET CRLF, where RFC 9112 section 7.1 allows only an optional ;-introduced chunk-ext. The same tolerance applies to the terminating zero-length chunk, which is the token that ends the message body.

3. Parser disagreement. The sibling Content-Length parser, Mint.HTTP1.Parse.content_length_header/1, trims trailing whitespace and requires the whole remaining value to be digits, rejecting anything else. An RFC-strict intermediary that rejects or reframes a chunk-size line with a non-extension tail, on a connection where Mint accepts it, yields a framing disagreement about chunk length and, through the terminating chunk, about where the message ends.

Proof of concept

1. Start a loopback TCP server that serves one HTTP/1.1 200 OK response with transfer-encoding: chunked and controls the chunk-size line byte for byte.
2. Connect with Mint.HTTP1 (mint 1.10.0 from Hex), send a request and stream the response.
3. Positive controls: chunk-size lines +5, Z5 and 00000000000000005 are refused with :invalid_chunk_size, confirming the build carries the earlier chunk-size fixes.
4. Baseline: 5 and 5;name=value are accepted with body hello.
5. Finding: 5ZZZZZ, 5 anything at all, 5<TAB>foo, 5 9 and 5}~! are each accepted as chunk size 5 with body hello.
6. Terminator: 0ZZZZ and 0 9 in place of the final 0 chunk are accepted and end the body.
7. Contrast: Content-Length: +5, Content-Length: 5ZZZ and Content-Length: 5 9 are refused with :invalid_content_length_header in the same run.

The reporter ran this on Elixir 1.18 / OTP 27 and Elixir 1.18.4 / OTP 28 with identical results.

Impact

A malicious or attacker-influenced HTTP/1 origin behind an RFC-strict intermediary can make the intermediary and the Mint client disagree on chunk boundaries and on where the response body ends. On a pooled keep-alive connection that disagreement lets bytes from one response be attributed to the next, poisoning the responses returned to unrelated requests that share the connection.

Configurations

Exploitation requires a deployment topology in which an RFC-strict HTTP/1 intermediary (proxy, load balancer, or WAF) sits between the Mint client and the attacker-influenced origin, and HTTP/1 connections between the client and the intermediary are reused across requests (keep-alive with connection pooling). Mint clients that talk directly to an origin without an intermediary, or that do not reuse connections, are not exploitable for response-queue poisoning even if the vulnerable parsing behavior is present.

Summary

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

Two HTTP/1 response-parser states accumulate server data without any cap. In lib/mint/http1.ex, decode_status_line/4 stores the unconsumed data in conn.buffer when the status line is incomplete, and decode_body/5 does the same for an unterminated chunk-extension line. Both wait for a CRLF the server never has to send, and conn.buffer is prepended to every subsequent socket message. The :max_header_list_size budget is wired only into decode_headers/5 and decode_trailer_headers/4, so neither of these states is covered by it. A malicious server, or one reached through an attacker-controlled redirect or a fetched URL, streams bytes indefinitely until the BEAM node is killed by the operating system out-of-memory handler. The chunk-extension variant is reached after a valid status line and a complete, valid header section, so an intermediary inspecting only headers sees an ordinary 200 response.

This issue affects mint: from 0.1.0 before 1.10.0.

Summary

Inconsistent interpretation of HTTP requests (HTTP response smuggling) vulnerability in elixir-mint mint allows a malicious HTTP/1 server to desynchronize a strict intermediary and the Mint client on the same pooled connection, enabling response-queue poisoning against subsequent requests that share the connection.

The Mint.HTTP1.decode_body/5 function in lib/mint/http1.ex parses the chunk-size line of a Transfer-Encoding: chunked response with Integer.parse(data, 16). RFC 7230 defines chunk-size = 1*HEXDIG and forbids any sign prefix, but Integer.parse/2 accepts an optional leading + or -. A chunk-size line of +5 is accepted as a five-byte chunk; lines of +0 and -0 are accepted as the terminating zero-length chunk and end the message body early.

An RFC-strict intermediary in the response path rejects these forms, so the intermediary and the Mint client disagree on where one response ends and the next begins. On a pooled keep-alive connection, an attacker-influenced origin can inject bytes that the client attributes to the next legitimate response on the same connection, poisoning the response queue and corrupting the responses returned to unrelated in-flight requests.

This issue affects mint: from 0.1.0 before 1.9.3.

Configurations

Exploitation requires a deployment topology in which an RFC-strict HTTP/1 intermediary (proxy, load balancer, or WAF) sits between the Mint client and the attacker-influenced origin, and HTTP/1 connections between the client and the intermediary are reused across requests (keep-alive with connection pooling). Mint clients that talk directly to an origin without an intermediary, or that do not reuse connections, are not exploitable for response-queue poisoning even if the vulnerable parsing behavior is present.

Summary

Allocation of resources without limits vulnerability in elixir-mint mint allows a remote HTTP/2 server to exhaust memory on the client host and cause a denial of service.

The Mint.HTTP2.handle_continuation/3 function in lib/mint/http2.ex accumulates the header-block fragment carried by each HTTP/2 CONTINUATION frame into a growing conn.headers_being_processed nesting, one level deeper per frame, and only releases it when a frame with the END_HEADERS flag arrives. The only guard on this accumulator is Mint.HTTP2.assert_header_block_within_max_size/2, which sums the byte size of the fragments received so far. Because a CONTINUATION frame is permitted by the protocol to carry a zero-length payload, an unbounded chain of zero-length CONTINUATION frames adds no bytes to the running total, never trips the size cap, and never emits END_HEADERS, yet each frame still nests the accumulator one level deeper.

A malicious HTTP/2 server (reachable directly, via an attacker-controlled redirect, via SSRF, or via a man-in-the-middle) can open a stream by sending a HEADERS frame without END_HEADERS and then stream zero-length CONTINUATION frames indefinitely. Client memory grows one cons cell per frame received; sustained bandwidth from the peer drives the BEAM node running the Mint client to memory exhaustion and eventual out-of-memory termination.

This issue affects mint: from 0.1.0 before 1.9.2.

Summary

Allocation of resources without limits vulnerability in elixir-mint mint allows a remote HTTP server to exhaust memory on the client host and cause a denial of service.

The Mint.HTTP1.decode_headers/5 and Mint.HTTP1.decode_trailer_headers/4 functions in lib/mint/http1.ex accumulate every parsed response header and chunked-trailer field into a per-request list that persists across incoming TCP segments as request.headers_buffer, and only clear it when the terminating blank line is received. The section has no cap on the number of headers or on total bytes, and the underlying :erlang.decode_packet(:httph_bin, binary, []) parser is invoked with an empty option list so its per-line and per-packet size limits also default to unlimited.

A malicious HTTP server (reachable directly, via an attacker-controlled redirect, via SSRF, or via a man-in-the-middle) can stream complete header lines (or, after a chunked body, complete trailer lines) indefinitely without ever emitting the terminating blank line. The connection state grows without bound until the BEAM node is killed by the operating system's out-of-memory handler, taking down the entire application that uses Mint as an HTTP client.

This issue affects mint: from 0.1.0 before 1.9.2.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in elixir-mint mint (Mint.HTTP1 module) allows a denial of service via an oversized chunked transfer-encoded response.

This vulnerability is associated with program files lib/mint/http1.ex and program routines 'Elixir.Mint.HTTP1':decode_body/5, 'Elixir.Mint.HTTP1':add_body_to_buffer/2.

When Mint decodes a chunked HTTP response body, it accumulates each partial fragment of the current chunk in the connection's data_buffer (an unbounded iolist) via add_body_to_buffer/2 and does not emit the data to the caller until the full declared chunk length has been received. The chunk size is taken directly from the server and parsed with no upper bound, so a malicious or compromised server can announce one enormous chunk (for example a size line of 7FFFFFFF, about 2 GiB) and then send the body bytes slowly without ever completing the chunk. The client buffers every received byte while it waits for a completion that never arrives, and because no data responses are produced until the chunk finishes, a caller that otherwise streams large content-length bodies safely gains no protection. An unauthenticated remote server (reachable whenever a client follows redirects, fetches user-supplied URLs, or processes webhooks) can drive the client's memory arbitrarily high and trigger an out-of-memory condition.

This issue affects mint: from 0.5.0 before 1.9.1.

Summary

Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') vulnerability in elixir-mint mint allows a malicious HTTP/1 server to desynchronize an intermediary and the Mint client on a pooled connection, poisoning the responses to subsequent requests that share the connection.

message_body/1 in lib/mint/http1.ex selects chunked framing when chunked is the first coding listed in a response's Transfer-Encoding fields. RFC 9112 section 6.3 applies chunked framing only when chunked is the final coding, and otherwise reads the body until the server closes the connection. For a response such as Transfer-Encoding: chunked, gzip, an intermediary that follows the RFC treats every byte up to the close as the body, while Mint ends the body at the zero-length chunk and parses the remaining bytes as the response to the next request on the connection.

Mint also keeps the connection open after an HTTP/1.0 response, final or 1xx, that carries Transfer-Encoding and Connection: keep-alive. RFC 9112 section 6.1 requires treating the framing of such a message as faulty and closing the connection after it, so bytes after its chunked body are parsed as the response to the next request in the same way.

This issue affects mint: from 0.1.0 before 1.10.2.

Details

1. Coding list. store_header/3 in lib/mint/http1.ex tokenizes each Transfer-Encoding field with Mint.HTTP1.Parse.transfer_encoding_header/1 and appends the codings to request.transfer_encoding in the order received.

2. Framing decision. message_body/1 returns chunked framing when List.first(request.transfer_encoding) is "chunked". The only other Transfer-Encoding check rejects a response that also carries Content-Length, so chunked, gzip on its own is framed as chunked.

3. Leftover bytes. decode_body/5 ends the body at the zero-length chunk and its trailer section, and next_request/3 keeps the rest of the data in conn.buffer or decodes it immediately as the next queued response. An RFC 9112 intermediary frames the same response as ending at connection close, so bytes it forwarded as body of the first response become the response to the next request on the Mint connection, and that request's real response is left in the buffer for the one after it.

4. HTTP/1.0 keep-alive. request_done/2 keeps an HTTP/1.0 connection open when the response has Connection: keep-alive, without checking for Transfer-Encoding, and decode_body(:informational, ...) resets the framing state of a 1xx response and keeps parsing. An HTTP/1.0 response with Transfer-Encoding: chunked and Connection: keep-alive therefore leaves the connection open after its chunked body, and the following bytes are decoded as the next queued response, although RFC 9112 section 6.1 requires closing the connection after such a message.

Proof of concept

1. Start a loopback TCP server that answers the first request with HTTP/1.1 200 OK and Transfer-Encoding: chunked, gzip, the chunked body 5\r\nLEGIT\r\n0\r\n\r\n, and directly after it the bytes HTTP/1.1 200 OK\r\nContent-Length: 8\r\n\r\nSMUGGLED.
2. Connect with Mint.HTTP1 and send a request. Mint returns LEGIT as the complete body, keeps the connection open, and holds the second response in conn.buffer.
3. Send a second request on the same connection and have the server answer it with a real response. Mint returns SMUGGLED as the response to the second request and keeps the real one in the buffer.
4. Pipelining both requests before the server answers gives the same result from a single Mint.HTTP1.stream/2 call.

Impact

A malicious or attacker-influenced HTTP/1 origin behind an intermediary that follows RFC 9112 framing can make the intermediary and the Mint client disagree on where a response ends. On a pooled keep-alive connection, bytes the origin appends to one response become the response to the next request sharing the connection, and the real responses shift to later requests.

Configurations

Exploitation requires an HTTP/1 intermediary (proxy, load balancer, or gateway) between the Mint client and the attacker-influenced origin that frames a response whose final transfer coding is not chunked as ending at connection close and forwards its Transfer-Encoding header to the client unchanged, and HTTP/1 connections between the client and the intermediary that are reused across requests. Intermediaries that reject such a header or re-frame the body do not create the disagreement. Mint clients that connect to the origin directly, or that don't reuse connections, aren't exposed to response-queue poisoning.

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.10.2.

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.

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.10.2.

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.

Summary

Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') vulnerability in elixir-mint mint allows a malicious HTTP/1 server to desynchronize a strict intermediary and the Mint client on a pooled connection, enabling response-queue poisoning against subsequent requests that share the connection.

Mint.HTTP1.Parse.chunk_size/1 in lib/mint/http1/parse.ex stops at the first non-hexadecimal byte of a chunked response's chunk-size line and returns the remainder unexamined. Mint.HTTP1.decode_body/5 in lib/mint/http1.ex then discards every byte up to the CRLF with Parse.ignore_until_crlf/1, so the accepted grammar is a run of hex digits followed by arbitrary bytes, where RFC 9112 permits only a ;-introduced chunk extension. Lines such as 5ZZZZZ and 5 9 are accepted as chunk size 5, and 0ZZZZ is accepted as the terminating chunk that ends the message body. An RFC-strict intermediary rejects such a line while Mint accepts it, so the two disagree on chunk boundaries and on where the response ends.

This issue affects mint: from 0.1.0 before 1.10.1.

Details

1. Chunk-size parsing. Mint.HTTP1.Parse.chunk_size/1 in lib/mint/http1/parse.ex folds leading hexadecimal digits into an accumulator through parse_hex_prefix/3 and, on the first byte that is not a hex digit, returns {:ok, size, rest} with rest unexamined. The sign and digit-count checks added by earlier fixes constrain only the digits.

2. Tail skipping. The caller, Mint.HTTP1.decode_body/5 in lib/mint/http1.ex, hands rest to Parse.ignore_until_crlf/1, which advances over any byte until it finds CRLF. Nothing between the last hex digit and the CRLF is validated, so the accepted grammar is 1*HEXDIG *OCTET CRLF, where RFC 9112 section 7.1 allows only an optional ;-introduced chunk-ext. The same tolerance applies to the terminating zero-length chunk, which is the token that ends the message body.

3. Parser disagreement. The sibling Content-Length parser, Mint.HTTP1.Parse.content_length_header/1, trims trailing whitespace and requires the whole remaining value to be digits, rejecting anything else. An RFC-strict intermediary that rejects or reframes a chunk-size line with a non-extension tail, on a connection where Mint accepts it, yields a framing disagreement about chunk length and, through the terminating chunk, about where the message ends.

Proof of concept

1. Start a loopback TCP server that serves one HTTP/1.1 200 OK response with transfer-encoding: chunked and controls the chunk-size line byte for byte.
2. Connect with Mint.HTTP1 (mint 1.10.0 from Hex), send a request and stream the response.
3. Positive controls: chunk-size lines +5, Z5 and 00000000000000005 are refused with :invalid_chunk_size, confirming the build carries the earlier chunk-size fixes.
4. Baseline: 5 and 5;name=value are accepted with body hello.
5. Finding: 5ZZZZZ, 5 anything at all, 5<TAB>foo, 5 9 and 5}~! are each accepted as chunk size 5 with body hello.
6. Terminator: 0ZZZZ and 0 9 in place of the final 0 chunk are accepted and end the body.
7. Contrast: Content-Length: +5, Content-Length: 5ZZZ and Content-Length: 5 9 are refused with :invalid_content_length_header in the same run.

The reporter ran this on Elixir 1.18 / OTP 27 and Elixir 1.18.4 / OTP 28 with identical results.

Impact

A malicious or attacker-influenced HTTP/1 origin behind an RFC-strict intermediary can make the intermediary and the Mint client disagree on chunk boundaries and on where the response body ends. On a pooled keep-alive connection that disagreement lets bytes from one response be attributed to the next, poisoning the responses returned to unrelated requests that share the connection.

Configurations

Exploitation requires a deployment topology in which an RFC-strict HTTP/1 intermediary (proxy, load balancer, or WAF) sits between the Mint client and the attacker-influenced origin, and HTTP/1 connections between the client and the intermediary are reused across requests (keep-alive with connection pooling). Mint clients that talk directly to an origin without an intermediary, or that do not reuse connections, are not exploitable for response-queue poisoning even if the vulnerable parsing behavior is present.

Summary

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

Two HTTP/1 response-parser states accumulate server data without any cap. In lib/mint/http1.ex, decode_status_line/4 stores the unconsumed data in conn.buffer when the status line is incomplete, and decode_body/5 does the same for an unterminated chunk-extension line. Both wait for a CRLF the server never has to send, and conn.buffer is prepended to every subsequent socket message. The :max_header_list_size budget is wired only into decode_headers/5 and decode_trailer_headers/4, so neither of these states is covered by it. A malicious server, or one reached through an attacker-controlled redirect or a fetched URL, streams bytes indefinitely until the BEAM node is killed by the operating system out-of-memory handler. The chunk-extension variant is reached after a valid status line and a complete, valid header section, so an intermediary inspecting only headers sees an ordinary 200 response.

This issue affects mint: from 0.1.0 before 1.10.0.

Summary

Inconsistent interpretation of HTTP requests (HTTP response smuggling) vulnerability in elixir-mint mint allows a malicious HTTP/1 server to desynchronize a strict intermediary and the Mint client on the same pooled connection, enabling response-queue poisoning against subsequent requests that share the connection.

The Mint.HTTP1.decode_body/5 function in lib/mint/http1.ex parses the chunk-size line of a Transfer-Encoding: chunked response with Integer.parse(data, 16). RFC 7230 defines chunk-size = 1*HEXDIG and forbids any sign prefix, but Integer.parse/2 accepts an optional leading + or -. A chunk-size line of +5 is accepted as a five-byte chunk; lines of +0 and -0 are accepted as the terminating zero-length chunk and end the message body early.

An RFC-strict intermediary in the response path rejects these forms, so the intermediary and the Mint client disagree on where one response ends and the next begins. On a pooled keep-alive connection, an attacker-influenced origin can inject bytes that the client attributes to the next legitimate response on the same connection, poisoning the response queue and corrupting the responses returned to unrelated in-flight requests.

This issue affects mint: from 0.1.0 before 1.9.3.

Configurations

Exploitation requires a deployment topology in which an RFC-strict HTTP/1 intermediary (proxy, load balancer, or WAF) sits between the Mint client and the attacker-influenced origin, and HTTP/1 connections between the client and the intermediary are reused across requests (keep-alive with connection pooling). Mint clients that talk directly to an origin without an intermediary, or that do not reuse connections, are not exploitable for response-queue poisoning even if the vulnerable parsing behavior is present.

Summary

Allocation of resources without limits vulnerability in elixir-mint mint allows a remote HTTP/2 server to exhaust memory on the client host and cause a denial of service.

The Mint.HTTP2.handle_continuation/3 function in lib/mint/http2.ex accumulates the header-block fragment carried by each HTTP/2 CONTINUATION frame into a growing conn.headers_being_processed nesting, one level deeper per frame, and only releases it when a frame with the END_HEADERS flag arrives. The only guard on this accumulator is Mint.HTTP2.assert_header_block_within_max_size/2, which sums the byte size of the fragments received so far. Because a CONTINUATION frame is permitted by the protocol to carry a zero-length payload, an unbounded chain of zero-length CONTINUATION frames adds no bytes to the running total, never trips the size cap, and never emits END_HEADERS, yet each frame still nests the accumulator one level deeper.

A malicious HTTP/2 server (reachable directly, via an attacker-controlled redirect, via SSRF, or via a man-in-the-middle) can open a stream by sending a HEADERS frame without END_HEADERS and then stream zero-length CONTINUATION frames indefinitely. Client memory grows one cons cell per frame received; sustained bandwidth from the peer drives the BEAM node running the Mint client to memory exhaustion and eventual out-of-memory termination.

This issue affects mint: from 0.1.0 before 1.9.2.

Summary

Allocation of resources without limits vulnerability in elixir-mint mint allows a remote HTTP server to exhaust memory on the client host and cause a denial of service.

The Mint.HTTP1.decode_headers/5 and Mint.HTTP1.decode_trailer_headers/4 functions in lib/mint/http1.ex accumulate every parsed response header and chunked-trailer field into a per-request list that persists across incoming TCP segments as request.headers_buffer, and only clear it when the terminating blank line is received. The section has no cap on the number of headers or on total bytes, and the underlying :erlang.decode_packet(:httph_bin, binary, []) parser is invoked with an empty option list so its per-line and per-packet size limits also default to unlimited.

A malicious HTTP server (reachable directly, via an attacker-controlled redirect, via SSRF, or via a man-in-the-middle) can stream complete header lines (or, after a chunked body, complete trailer lines) indefinitely without ever emitting the terminating blank line. The connection state grows without bound until the BEAM node is killed by the operating system's out-of-memory handler, taking down the entire application that uses Mint as an HTTP client.

This issue affects mint: from 0.1.0 before 1.9.2.

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 handshake and ACKs the client's SETTINGS.
2. Wait for the client's request HEADERS and capture its odd stream ID.
3. Send a flood of PUSH_PROMISE frames (flags = END_HEADERS) associated with the captured stream, each promising a fresh even stream ID and carrying a minimal HPACK-encoded header block.
4. Never send the matching response HEADERS for any of the promised IDs.
5. The client's conn.streams map grows by one entry per PUSH_PROMISE frame (~148 bytes/entry); memory grows linearly and the BEAM process eventually crashes with OOM.

Impact

Remote, unauthenticated denial-of-service against any process using Mint as an HTTP/2 client against an untrusted or attacker-influenced server. Server push is on by default, so no application code change can prevent it short of disabling push or upgrading. Affected populations include outbound HTTP/2 clients in web backends, webhook delivery systems, scrapers, federated and proxy components, and any service that follows redirects to third-party HTTP/2 origins.

Workarounds

Disable HTTP/2 server push on connections to untrusted servers by passing client_settings: [enable_push: false] to 'Elixir.Mint.HTTP':connect/4. Mint will then reject any inbound PUSH_PROMISE frame with a PROTOCOL_ERROR before the vulnerable code path is reached.

Resources

• Introduction commit: https://github.com/elixir-mint/mint/commit/65c6394d05a1b8aa4a7461708c3aa173e8d7a5cf
• Patch commit: https://github.com/elixir-mint/mint/commit/70b97b6a5209fb288b0e04d8e657dda26c59de67

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 flags = 0 (no END_HEADERS, no END_STREAM) and an empty header-block fragment.
3. Stream CONTINUATION frames on stream 1, each with flags = 0 and a payload up to SETTINGS_MAX_FRAME_SIZE. Never set END_HEADERS.
4. The client's process memory grows linearly with the flood and the BEAM process eventually crashes with OOM.

Impact

Remote, unauthenticated denial-of-service against any process using Mint as an HTTP/2 client against an untrusted or attacker-influenced server. A single connection is sufficient to drive memory to arbitrary size and crash the BEAM process. The default Mint configuration is vulnerable; no client-side opt-in is required. Scored CVSS v4.0 8.2 (HIGH).

Workarounds

Restrict Mint to HTTP/1 on connections to untrusted servers by passing protocols: [:http1] to 'Elixir.Mint.HTTP':connect/4. This avoids the vulnerable HTTP/2 receive path entirely, at the cost of losing HTTP/2 for those connections.

Resources

• Introduction commit: https://github.com/elixir-mint/mint/commit/596ca4304504be68939c4929e0831557097962b8
• Patch commit: https://github.com/elixir-mint/mint/commit/b662d127d3028b5426c88d4c9cc7fe430491a10b

Summary

Mint's HTTP/1 client accepts Content-Length header values with a leading + sign (e.g. +0, +123), which RFC 7230 forbids (Content-Length = 1*DIGIT). On a connection shared with a strict fronting proxy or load balancer, this parser disagreement is a response-smuggling primitive: the proxy frames the body one way, Mint frames it another, and bytes meant for one response leak into the next consumer's response stream.

Details

'Elixir.Mint.HTTP1.Parse':content_length_header/1 in lib/mint/http1/parse.ex parses the header value with Integer.parse/1. By design, Integer.parse/1 accepts an optional + or - sign prefix. The length >= 0 guard rules out negatives, but inputs such as "+0", "+123", or "+1" pass through and are returned as valid lengths.

A strict proxy or load balancer rejects or reframes Content-Length: +0\r\n, while Mint silently treats it as 0. When Mint reuses the socket (keep-alive, pipelining, or any pooled connection) and the connection is shared with a proxy that frames the same bytes differently, trailing bytes the proxy attributes to response N are attributed by Mint to response N+1. Across trust boundaries (shared pools, multi-tenant fronting) this enables response smuggling.

PoC

1. Stand up a raw TCP server that returns HTTP/1.1 200 OK\r\nContent-Length: +0\r\nConnection: keep-alive\r\n\r\n<smuggled bytes>.
2. Connect a Mint HTTP/1 client to the server and issue a request.
3. Observe that Mint reports the response as status 200 with Content-Length: "+0" and an empty body, leaving the smuggled bytes sitting in the socket buffer for the next response.

Impact

Response-smuggling / request-response desync primitive in Mint's HTTP/1 client parser. Anyone using Mint (directly or via Finch, Tesla's Mint adapter, Req, etc.) to talk through a shared or pooled connection where a fronting proxy enforces RFC 7230 strictly while Mint does not is exposed. The attacker is the response producer (a malicious or compromised upstream, or anything that can inject bytes into a shared origin response); exploitation into a cross-request data leak additionally requires the deployment to share a Mint connection across trust boundaries.

Resources

• Introduction commit: https://github.com/elixir-mint/mint/commit/65e0e86d799a6d3b08e4372fccdd9747535e0dd6
• Patch commit: https://github.com/elixir-mint/mint/commit/47e48027480228e4e32a0b4df39db497b4804921

Summary

Mint's HTTP/1 request encoder splices the caller-supplied method and target directly into the request line without character validation. An application that forwards attacker-controlled input as the HTTP method or the target to Mint.HTTP.request/5 is exposed to request-line CRLF injection, allowing the attacker to terminate the request line early, inject arbitrary headers, and pipeline a fully attacker-chosen second request onto the same TCP connection.

Details

encode_request_line/2 in lib/mint/http1/request.ex writes method and target to the wire verbatim. encode_headers/1 validates header names and values, but there is no equivalent validate_method!/1.

Mint 1.7.0 added validate_request_target/2, which rejects CRLF and other control characters in target by default and closes the path/query vector. The method field remains unvalidated, so a CRLF-bearing method such as "GET / HTTP/1.1\r\nX-Smuggled: 1\r\nGET /admin" is accepted and written to the socket as-is. Bytes after the first \r\n are interpreted by the peer as an injected header, or, with a second \r\n, as an additional pipelined request.

PoC

1. Stand up a Mint-using gateway/proxy that calls Mint.HTTP.request(conn, method, "/", [], nil) with method taken from caller input.
2. Send a request whose forwarded method is "GET / HTTP/1.1\r\nX-Smuggled-Header: pwned\r\nGET /admin/delete-everything".
3. Observe the bytes received by the upstream server: the smuggled header line and the second request line appear verbatim in the outbound stream.

Impact

CRLF injection / HTTP request smuggling in the HTTP/1 client encoder, exploitable under default configuration whenever an application passes caller-influenced input as the HTTP method. An attacker who controls the method can inject arbitrary outbound headers (forged Host, Authorization, cache-poisoning headers) and smuggle additional, fully attacker-chosen requests to the upstream server over the same connection, potentially reaching endpoints the legitimate caller never intended to invoke.

Resources

• Introduction commit: https://github.com/elixir-mint/mint/commit/8db1acff30b6a9433762c18b1e1f891b8c1f74f7
• Patch commit: https://github.com/elixir-mint/mint/commit/fad091454cbb7449b19edb8e1fee12ca7cf28c3a

Summary

Allocation of Resources Without Limits or Throttling vulnerability in elixir-mint mint (Mint.HTTP1 module) allows a denial of service via an oversized chunked transfer-encoded response.

This vulnerability is associated with program files lib/mint/http1.ex and program routines 'Elixir.Mint.HTTP1':decode_body/5, 'Elixir.Mint.HTTP1':add_body_to_buffer/2.

When Mint decodes a chunked HTTP response body, it accumulates each partial fragment of the current chunk in the connection's data_buffer (an unbounded iolist) via add_body_to_buffer/2 and does not emit the data to the caller until the full declared chunk length has been received. The chunk size is taken directly from the server and parsed with no upper bound, so a malicious or compromised server can announce one enormous chunk (for example a size line of 7FFFFFFF, about 2 GiB) and then send the body bytes slowly without ever completing the chunk. The client buffers every received byte while it waits for a completion that never arrives, and because no data responses are produced until the chunk finishes, a caller that otherwise streams large content-length bodies safely gains no protection. An unauthenticated remote server (reachable whenever a client follows redirects, fetches user-supplied URLs, or processes webhooks) can drive the client's memory arbitrarily high and trigger an out-of-memory condition.

This issue affects mint: from 0.5.0 before 1.9.1.

Summary

Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') vulnerability in elixir-mint mint allows a malicious HTTP/1 server to desynchronize an intermediary and the Mint client on a pooled connection, poisoning the responses to subsequent requests that share the connection.

message_body/1 in lib/mint/http1.ex selects chunked framing when chunked is the first coding listed in a response's Transfer-Encoding fields. RFC 9112 section 6.3 applies chunked framing only when chunked is the final coding, and otherwise reads the body until the server closes the connection. For a response such as Transfer-Encoding: chunked, gzip, an intermediary that follows the RFC treats every byte up to the close as the body, while Mint ends the body at the zero-length chunk and parses the remaining bytes as the response to the next request on the connection.

Mint also keeps the connection open after an HTTP/1.0 response, final or 1xx, that carries Transfer-Encoding and Connection: keep-alive. RFC 9112 section 6.1 requires treating the framing of such a message as faulty and closing the connection after it, so bytes after its chunked body are parsed as the response to the next request in the same way.

This issue affects mint: from 0.1.0 before 1.10.2.

Details

1. Coding list. store_header/3 in lib/mint/http1.ex tokenizes each Transfer-Encoding field with Mint.HTTP1.Parse.transfer_encoding_header/1 and appends the codings to request.transfer_encoding in the order received.

2. Framing decision. message_body/1 returns chunked framing when List.first(request.transfer_encoding) is "chunked". The only other Transfer-Encoding check rejects a response that also carries Content-Length, so chunked, gzip on its own is framed as chunked.

3. Leftover bytes. decode_body/5 ends the body at the zero-length chunk and its trailer section, and next_request/3 keeps the rest of the data in conn.buffer or decodes it immediately as the next queued response. An RFC 9112 intermediary frames the same response as ending at connection close, so bytes it forwarded as body of the first response become the response to the next request on the Mint connection, and that request's real response is left in the buffer for the one after it.

4. HTTP/1.0 keep-alive. request_done/2 keeps an HTTP/1.0 connection open when the response has Connection: keep-alive, without checking for Transfer-Encoding, and decode_body(:informational, ...) resets the framing state of a 1xx response and keeps parsing. An HTTP/1.0 response with Transfer-Encoding: chunked and Connection: keep-alive therefore leaves the connection open after its chunked body, and the following bytes are decoded as the next queued response, although RFC 9112 section 6.1 requires closing the connection after such a message.

Proof of concept

1. Start a loopback TCP server that answers the first request with HTTP/1.1 200 OK and Transfer-Encoding: chunked, gzip, the chunked body 5\r\nLEGIT\r\n0\r\n\r\n, and directly after it the bytes HTTP/1.1 200 OK\r\nContent-Length: 8\r\n\r\nSMUGGLED.
2. Connect with Mint.HTTP1 and send a request. Mint returns LEGIT as the complete body, keeps the connection open, and holds the second response in conn.buffer.
3. Send a second request on the same connection and have the server answer it with a real response. Mint returns SMUGGLED as the response to the second request and keeps the real one in the buffer.
4. Pipelining both requests before the server answers gives the same result from a single Mint.HTTP1.stream/2 call.

Impact

A malicious or attacker-influenced HTTP/1 origin behind an intermediary that follows RFC 9112 framing can make the intermediary and the Mint client disagree on where a response ends. On a pooled keep-alive connection, bytes the origin appends to one response become the response to the next request sharing the connection, and the real responses shift to later requests.

Configurations

Exploitation requires an HTTP/1 intermediary (proxy, load balancer, or gateway) between the Mint client and the attacker-influenced origin that frames a response whose final transfer coding is not chunked as ending at connection close and forwards its Transfer-Encoding header to the client unchanged, and HTTP/1 connections between the client and the intermediary that are reused across requests. Intermediaries that reject such a header or re-frame the body do not create the disagreement. Mint clients that connect to the origin directly, or that don't reuse connections, aren't exposed to response-queue poisoning.

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.10.2.

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.

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.10.2.

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.

Summary

Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') vulnerability in elixir-mint mint allows a malicious HTTP/1 server to desynchronize a strict intermediary and the Mint client on a pooled connection, enabling response-queue poisoning against subsequent requests that share the connection.

Mint.HTTP1.Parse.chunk_size/1 in lib/mint/http1/parse.ex stops at the first non-hexadecimal byte of a chunked response's chunk-size line and returns the remainder unexamined. Mint.HTTP1.decode_body/5 in lib/mint/http1.ex then discards every byte up to the CRLF with Parse.ignore_until_crlf/1, so the accepted grammar is a run of hex digits followed by arbitrary bytes, where RFC 9112 permits only a ;-introduced chunk extension. Lines such as 5ZZZZZ and 5 9 are accepted as chunk size 5, and 0ZZZZ is accepted as the terminating chunk that ends the message body. An RFC-strict intermediary rejects such a line while Mint accepts it, so the two disagree on chunk boundaries and on where the response ends.

This issue affects mint: from 0.1.0 before 1.10.1.

Details

1. Chunk-size parsing. Mint.HTTP1.Parse.chunk_size/1 in lib/mint/http1/parse.ex folds leading hexadecimal digits into an accumulator through parse_hex_prefix/3 and, on the first byte that is not a hex digit, returns {:ok, size, rest} with rest unexamined. The sign and digit-count checks added by earlier fixes constrain only the digits.

2. Tail skipping. The caller, Mint.HTTP1.decode_body/5 in lib/mint/http1.ex, hands rest to Parse.ignore_until_crlf/1, which advances over any byte until it finds CRLF. Nothing between the last hex digit and the CRLF is validated, so the accepted grammar is 1*HEXDIG *OCTET CRLF, where RFC 9112 section 7.1 allows only an optional ;-introduced chunk-ext. The same tolerance applies to the terminating zero-length chunk, which is the token that ends the message body.

3. Parser disagreement. The sibling Content-Length parser, Mint.HTTP1.Parse.content_length_header/1, trims trailing whitespace and requires the whole remaining value to be digits, rejecting anything else. An RFC-strict intermediary that rejects or reframes a chunk-size line with a non-extension tail, on a connection where Mint accepts it, yields a framing disagreement about chunk length and, through the terminating chunk, about where the message ends.

Proof of concept

1. Start a loopback TCP server that serves one HTTP/1.1 200 OK response with transfer-encoding: chunked and controls the chunk-size line byte for byte.
2. Connect with Mint.HTTP1 (mint 1.10.0 from Hex), send a request and stream the response.
3. Positive controls: chunk-size lines +5, Z5 and 00000000000000005 are refused with :invalid_chunk_size, confirming the build carries the earlier chunk-size fixes.
4. Baseline: 5 and 5;name=value are accepted with body hello.
5. Finding: 5ZZZZZ, 5 anything at all, 5<TAB>foo, 5 9 and 5}~! are each accepted as chunk size 5 with body hello.
6. Terminator: 0ZZZZ and 0 9 in place of the final 0 chunk are accepted and end the body.
7. Contrast: Content-Length: +5, Content-Length: 5ZZZ and Content-Length: 5 9 are refused with :invalid_content_length_header in the same run.

The reporter ran this on Elixir 1.18 / OTP 27 and Elixir 1.18.4 / OTP 28 with identical results.

Impact

A malicious or attacker-influenced HTTP/1 origin behind an RFC-strict intermediary can make the intermediary and the Mint client disagree on chunk boundaries and on where the response body ends. On a pooled keep-alive connection that disagreement lets bytes from one response be attributed to the next, poisoning the responses returned to unrelated requests that share the connection.

Configurations

Exploitation requires a deployment topology in which an RFC-strict HTTP/1 intermediary (proxy, load balancer, or WAF) sits between the Mint client and the attacker-influenced origin, and HTTP/1 connections between the client and the intermediary are reused across requests (keep-alive with connection pooling). Mint clients that talk directly to an origin without an intermediary, or that do not reuse connections, are not exploitable for response-queue poisoning even if the vulnerable parsing behavior is present.

Summary

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

Two HTTP/1 response-parser states accumulate server data without any cap. In lib/mint/http1.ex, decode_status_line/4 stores the unconsumed data in conn.buffer when the status line is incomplete, and decode_body/5 does the same for an unterminated chunk-extension line. Both wait for a CRLF the server never has to send, and conn.buffer is prepended to every subsequent socket message. The :max_header_list_size budget is wired only into decode_headers/5 and decode_trailer_headers/4, so neither of these states is covered by it. A malicious server, or one reached through an attacker-controlled redirect or a fetched URL, streams bytes indefinitely until the BEAM node is killed by the operating system out-of-memory handler. The chunk-extension variant is reached after a valid status line and a complete, valid header section, so an intermediary inspecting only headers sees an ordinary 200 response.

This issue affects mint: from 0.1.0 before 1.10.0.

Summary

Inconsistent interpretation of HTTP requests (HTTP response smuggling) vulnerability in elixir-mint mint allows a malicious HTTP/1 server to desynchronize a strict intermediary and the Mint client on the same pooled connection, enabling response-queue poisoning against subsequent requests that share the connection.

The Mint.HTTP1.decode_body/5 function in lib/mint/http1.ex parses the chunk-size line of a Transfer-Encoding: chunked response with Integer.parse(data, 16). RFC 7230 defines chunk-size = 1*HEXDIG and forbids any sign prefix, but Integer.parse/2 accepts an optional leading + or -. A chunk-size line of +5 is accepted as a five-byte chunk; lines of +0 and -0 are accepted as the terminating zero-length chunk and end the message body early.

An RFC-strict intermediary in the response path rejects these forms, so the intermediary and the Mint client disagree on where one response ends and the next begins. On a pooled keep-alive connection, an attacker-influenced origin can inject bytes that the client attributes to the next legitimate response on the same connection, poisoning the response queue and corrupting the responses returned to unrelated in-flight requests.

This issue affects mint: from 0.1.0 before 1.9.3.

Configurations

Exploitation requires a deployment topology in which an RFC-strict HTTP/1 intermediary (proxy, load balancer, or WAF) sits between the Mint client and the attacker-influenced origin, and HTTP/1 connections between the client and the intermediary are reused across requests (keep-alive with connection pooling). Mint clients that talk directly to an origin without an intermediary, or that do not reuse connections, are not exploitable for response-queue poisoning even if the vulnerable parsing behavior is present.

Summary

Allocation of resources without limits vulnerability in elixir-mint mint allows a remote HTTP/2 server to exhaust memory on the client host and cause a denial of service.

The Mint.HTTP2.handle_continuation/3 function in lib/mint/http2.ex accumulates the header-block fragment carried by each HTTP/2 CONTINUATION frame into a growing conn.headers_being_processed nesting, one level deeper per frame, and only releases it when a frame with the END_HEADERS flag arrives. The only guard on this accumulator is Mint.HTTP2.assert_header_block_within_max_size/2, which sums the byte size of the fragments received so far. Because a CONTINUATION frame is permitted by the protocol to carry a zero-length payload, an unbounded chain of zero-length CONTINUATION frames adds no bytes to the running total, never trips the size cap, and never emits END_HEADERS, yet each frame still nests the accumulator one level deeper.

A malicious HTTP/2 server (reachable directly, via an attacker-controlled redirect, via SSRF, or via a man-in-the-middle) can open a stream by sending a HEADERS frame without END_HEADERS and then stream zero-length CONTINUATION frames indefinitely. Client memory grows one cons cell per frame received; sustained bandwidth from the peer drives the BEAM node running the Mint client to memory exhaustion and eventual out-of-memory termination.

This issue affects mint: from 0.1.0 before 1.9.2.

Summary

Allocation of resources without limits vulnerability in elixir-mint mint allows a remote HTTP server to exhaust memory on the client host and cause a denial of service.

The Mint.HTTP1.decode_headers/5 and Mint.HTTP1.decode_trailer_headers/4 functions in lib/mint/http1.ex accumulate every parsed response header and chunked-trailer field into a per-request list that persists across incoming TCP segments as request.headers_buffer, and only clear it when the terminating blank line is received. The section has no cap on the number of headers or on total bytes, and the underlying :erlang.decode_packet(:httph_bin, binary, []) parser is invoked with an empty option list so its per-line and per-packet size limits also default to unlimited.

A malicious HTTP server (reachable directly, via an attacker-controlled redirect, via SSRF, or via a man-in-the-middle) can stream complete header lines (or, after a chunked body, complete trailer lines) indefinitely without ever emitting the terminating blank line. The connection state grows without bound until the BEAM node is killed by the operating system's out-of-memory handler, taking down the entire application that uses Mint as an HTTP client.

This issue affects mint: from 0.1.0 before 1.9.2.

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 handshake and ACKs the client's SETTINGS.
2. Wait for the client's request HEADERS and capture its odd stream ID.
3. Send a flood of PUSH_PROMISE frames (flags = END_HEADERS) associated with the captured stream, each promising a fresh even stream ID and carrying a minimal HPACK-encoded header block.
4. Never send the matching response HEADERS for any of the promised IDs.
5. The client's conn.streams map grows by one entry per PUSH_PROMISE frame (~148 bytes/entry); memory grows linearly and the BEAM process eventually crashes with OOM.

Impact

Remote, unauthenticated denial-of-service against any process using Mint as an HTTP/2 client against an untrusted or attacker-influenced server. Server push is on by default, so no application code change can prevent it short of disabling push or upgrading. Affected populations include outbound HTTP/2 clients in web backends, webhook delivery systems, scrapers, federated and proxy components, and any service that follows redirects to third-party HTTP/2 origins.

Workarounds

Disable HTTP/2 server push on connections to untrusted servers by passing client_settings: [enable_push: false] to 'Elixir.Mint.HTTP':connect/4. Mint will then reject any inbound PUSH_PROMISE frame with a PROTOCOL_ERROR before the vulnerable code path is reached.

Resources

• Introduction commit: https://github.com/elixir-mint/mint/commit/65c6394d05a1b8aa4a7461708c3aa173e8d7a5cf
• Patch commit: https://github.com/elixir-mint/mint/commit/70b97b6a5209fb288b0e04d8e657dda26c59de67

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 flags = 0 (no END_HEADERS, no END_STREAM) and an empty header-block fragment.
3. Stream CONTINUATION frames on stream 1, each with flags = 0 and a payload up to SETTINGS_MAX_FRAME_SIZE. Never set END_HEADERS.
4. The client's process memory grows linearly with the flood and the BEAM process eventually crashes with OOM.

Impact

Remote, unauthenticated denial-of-service against any process using Mint as an HTTP/2 client against an untrusted or attacker-influenced server. A single connection is sufficient to drive memory to arbitrary size and crash the BEAM process. The default Mint configuration is vulnerable; no client-side opt-in is required. Scored CVSS v4.0 8.2 (HIGH).

Workarounds

Restrict Mint to HTTP/1 on connections to untrusted servers by passing protocols: [:http1] to 'Elixir.Mint.HTTP':connect/4. This avoids the vulnerable HTTP/2 receive path entirely, at the cost of losing HTTP/2 for those connections.

Resources

• Introduction commit: https://github.com/elixir-mint/mint/commit/596ca4304504be68939c4929e0831557097962b8
• Patch commit: https://github.com/elixir-mint/mint/commit/b662d127d3028b5426c88d4c9cc7fe430491a10b

Summary

Mint's HTTP/1 client accepts Content-Length header values with a leading + sign (e.g. +0, +123), which RFC 7230 forbids (Content-Length = 1*DIGIT). On a connection shared with a strict fronting proxy or load balancer, this parser disagreement is a response-smuggling primitive: the proxy frames the body one way, Mint frames it another, and bytes meant for one response leak into the next consumer's response stream.

Details

'Elixir.Mint.HTTP1.Parse':content_length_header/1 in lib/mint/http1/parse.ex parses the header value with Integer.parse/1. By design, Integer.parse/1 accepts an optional + or - sign prefix. The length >= 0 guard rules out negatives, but inputs such as "+0", "+123", or "+1" pass through and are returned as valid lengths.

A strict proxy or load balancer rejects or reframes Content-Length: +0\r\n, while Mint silently treats it as 0. When Mint reuses the socket (keep-alive, pipelining, or any pooled connection) and the connection is shared with a proxy that frames the same bytes differently, trailing bytes the proxy attributes to response N are attributed by Mint to response N+1. Across trust boundaries (shared pools, multi-tenant fronting) this enables response smuggling.

PoC

1. Stand up a raw TCP server that returns HTTP/1.1 200 OK\r\nContent-Length: +0\r\nConnection: keep-alive\r\n\r\n<smuggled bytes>.
2. Connect a Mint HTTP/1 client to the server and issue a request.
3. Observe that Mint reports the response as status 200 with Content-Length: "+0" and an empty body, leaving the smuggled bytes sitting in the socket buffer for the next response.

Impact

Response-smuggling / request-response desync primitive in Mint's HTTP/1 client parser. Anyone using Mint (directly or via Finch, Tesla's Mint adapter, Req, etc.) to talk through a shared or pooled connection where a fronting proxy enforces RFC 7230 strictly while Mint does not is exposed. The attacker is the response producer (a malicious or compromised upstream, or anything that can inject bytes into a shared origin response); exploitation into a cross-request data leak additionally requires the deployment to share a Mint connection across trust boundaries.

Resources

• Introduction commit: https://github.com/elixir-mint/mint/commit/65e0e86d799a6d3b08e4372fccdd9747535e0dd6
• Patch commit: https://github.com/elixir-mint/mint/commit/47e48027480228e4e32a0b4df39db497b4804921

Summary

Mint's HTTP/1 request encoder splices the caller-supplied method and target directly into the request line without character validation. An application that forwards attacker-controlled input as the HTTP method or the target to Mint.HTTP.request/5 is exposed to request-line CRLF injection, allowing the attacker to terminate the request line early, inject arbitrary headers, and pipeline a fully attacker-chosen second request onto the same TCP connection.

Details

encode_request_line/2 in lib/mint/http1/request.ex writes method and target to the wire verbatim. encode_headers/1 validates header names and values, but there is no equivalent validate_method!/1.

Mint 1.7.0 added validate_request_target/2, which rejects CRLF and other control characters in target by default and closes the path/query vector. The method field remains unvalidated, so a CRLF-bearing method such as "GET / HTTP/1.1\r\nX-Smuggled: 1\r\nGET /admin" is accepted and written to the socket as-is. Bytes after the first \r\n are interpreted by the peer as an injected header, or, with a second \r\n, as an additional pipelined request.

PoC

1. Stand up a Mint-using gateway/proxy that calls Mint.HTTP.request(conn, method, "/", [], nil) with method taken from caller input.
2. Send a request whose forwarded method is "GET / HTTP/1.1\r\nX-Smuggled-Header: pwned\r\nGET /admin/delete-everything".
3. Observe the bytes received by the upstream server: the smuggled header line and the second request line appear verbatim in the outbound stream.

Impact

CRLF injection / HTTP request smuggling in the HTTP/1 client encoder, exploitable under default configuration whenever an application passes caller-influenced input as the HTTP method. An attacker who controls the method can inject arbitrary outbound headers (forged Host, Authorization, cache-poisoning headers) and smuggle additional, fully attacker-chosen requests to the upstream server over the same connection, potentially reaching endpoints the legitimate caller never intended to invoke.

Resources

• Introduction commit: https://github.com/elixir-mint/mint/commit/8db1acff30b6a9433762c18b1e1f891b8c1f74f7
• Patch commit: https://github.com/elixir-mint/mint/commit/fad091454cbb7449b19edb8e1fee12ca7cf28c3a

Summary

Allocation of Resources Without Limits or Throttling vulnerability in elixir-mint mint (Mint.HTTP1 module) allows a denial of service via an oversized chunked transfer-encoded response.

This vulnerability is associated with program files lib/mint/http1.ex and program routines 'Elixir.Mint.HTTP1':decode_body/5, 'Elixir.Mint.HTTP1':add_body_to_buffer/2.

When Mint decodes a chunked HTTP response body, it accumulates each partial fragment of the current chunk in the connection's data_buffer (an unbounded iolist) via add_body_to_buffer/2 and does not emit the data to the caller until the full declared chunk length has been received. The chunk size is taken directly from the server and parsed with no upper bound, so a malicious or compromised server can announce one enormous chunk (for example a size line of 7FFFFFFF, about 2 GiB) and then send the body bytes slowly without ever completing the chunk. The client buffers every received byte while it waits for a completion that never arrives, and because no data responses are produced until the chunk finishes, a caller that otherwise streams large content-length bodies safely gains no protection. An unauthenticated remote server (reachable whenever a client follows redirects, fetches user-supplied URLs, or processes webhooks) can drive the client's memory arbitrarily high and trigger an out-of-memory condition.

This issue affects mint: from 0.5.0 before 1.9.1.

Summary

Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') vulnerability in elixir-mint mint allows a malicious HTTP/1 server to desynchronize an intermediary and the Mint client on a pooled connection, poisoning the responses to subsequent requests that share the connection.

message_body/1 in lib/mint/http1.ex selects chunked framing when chunked is the first coding listed in a response's Transfer-Encoding fields. RFC 9112 section 6.3 applies chunked framing only when chunked is the final coding, and otherwise reads the body until the server closes the connection. For a response such as Transfer-Encoding: chunked, gzip, an intermediary that follows the RFC treats every byte up to the close as the body, while Mint ends the body at the zero-length chunk and parses the remaining bytes as the response to the next request on the connection.

Mint also keeps the connection open after an HTTP/1.0 response, final or 1xx, that carries Transfer-Encoding and Connection: keep-alive. RFC 9112 section 6.1 requires treating the framing of such a message as faulty and closing the connection after it, so bytes after its chunked body are parsed as the response to the next request in the same way.

This issue affects mint: from 0.1.0 before 1.10.2.

Details

1. Coding list. store_header/3 in lib/mint/http1.ex tokenizes each Transfer-Encoding field with Mint.HTTP1.Parse.transfer_encoding_header/1 and appends the codings to request.transfer_encoding in the order received.

2. Framing decision. message_body/1 returns chunked framing when List.first(request.transfer_encoding) is "chunked". The only other Transfer-Encoding check rejects a response that also carries Content-Length, so chunked, gzip on its own is framed as chunked.

3. Leftover bytes. decode_body/5 ends the body at the zero-length chunk and its trailer section, and next_request/3 keeps the rest of the data in conn.buffer or decodes it immediately as the next queued response. An RFC 9112 intermediary frames the same response as ending at connection close, so bytes it forwarded as body of the first response become the response to the next request on the Mint connection, and that request's real response is left in the buffer for the one after it.

4. HTTP/1.0 keep-alive. request_done/2 keeps an HTTP/1.0 connection open when the response has Connection: keep-alive, without checking for Transfer-Encoding, and decode_body(:informational, ...) resets the framing state of a 1xx response and keeps parsing. An HTTP/1.0 response with Transfer-Encoding: chunked and Connection: keep-alive therefore leaves the connection open after its chunked body, and the following bytes are decoded as the next queued response, although RFC 9112 section 6.1 requires closing the connection after such a message.

Proof of concept

1. Start a loopback TCP server that answers the first request with HTTP/1.1 200 OK and Transfer-Encoding: chunked, gzip, the chunked body 5\r\nLEGIT\r\n0\r\n\r\n, and directly after it the bytes HTTP/1.1 200 OK\r\nContent-Length: 8\r\n\r\nSMUGGLED.
2. Connect with Mint.HTTP1 and send a request. Mint returns LEGIT as the complete body, keeps the connection open, and holds the second response in conn.buffer.
3. Send a second request on the same connection and have the server answer it with a real response. Mint returns SMUGGLED as the response to the second request and keeps the real one in the buffer.
4. Pipelining both requests before the server answers gives the same result from a single Mint.HTTP1.stream/2 call.

Impact

A malicious or attacker-influenced HTTP/1 origin behind an intermediary that follows RFC 9112 framing can make the intermediary and the Mint client disagree on where a response ends. On a pooled keep-alive connection, bytes the origin appends to one response become the response to the next request sharing the connection, and the real responses shift to later requests.

Configurations

Exploitation requires an HTTP/1 intermediary (proxy, load balancer, or gateway) between the Mint client and the attacker-influenced origin that frames a response whose final transfer coding is not chunked as ending at connection close and forwards its Transfer-Encoding header to the client unchanged, and HTTP/1 connections between the client and the intermediary that are reused across requests. Intermediaries that reject such a header or re-frame the body do not create the disagreement. Mint clients that connect to the origin directly, or that don't reuse connections, aren't exposed to response-queue poisoning.

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.10.2.

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.

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.10.2.

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.

Summary

Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') vulnerability in elixir-mint mint allows a malicious HTTP/1 server to desynchronize a strict intermediary and the Mint client on a pooled connection, enabling response-queue poisoning against subsequent requests that share the connection.

Mint.HTTP1.Parse.chunk_size/1 in lib/mint/http1/parse.ex stops at the first non-hexadecimal byte of a chunked response's chunk-size line and returns the remainder unexamined. Mint.HTTP1.decode_body/5 in lib/mint/http1.ex then discards every byte up to the CRLF with Parse.ignore_until_crlf/1, so the accepted grammar is a run of hex digits followed by arbitrary bytes, where RFC 9112 permits only a ;-introduced chunk extension. Lines such as 5ZZZZZ and 5 9 are accepted as chunk size 5, and 0ZZZZ is accepted as the terminating chunk that ends the message body. An RFC-strict intermediary rejects such a line while Mint accepts it, so the two disagree on chunk boundaries and on where the response ends.

This issue affects mint: from 0.1.0 before 1.10.1.

Details

1. Chunk-size parsing. Mint.HTTP1.Parse.chunk_size/1 in lib/mint/http1/parse.ex folds leading hexadecimal digits into an accumulator through parse_hex_prefix/3 and, on the first byte that is not a hex digit, returns {:ok, size, rest} with rest unexamined. The sign and digit-count checks added by earlier fixes constrain only the digits.

2. Tail skipping. The caller, Mint.HTTP1.decode_body/5 in lib/mint/http1.ex, hands rest to Parse.ignore_until_crlf/1, which advances over any byte until it finds CRLF. Nothing between the last hex digit and the CRLF is validated, so the accepted grammar is 1*HEXDIG *OCTET CRLF, where RFC 9112 section 7.1 allows only an optional ;-introduced chunk-ext. The same tolerance applies to the terminating zero-length chunk, which is the token that ends the message body.

3. Parser disagreement. The sibling Content-Length parser, Mint.HTTP1.Parse.content_length_header/1, trims trailing whitespace and requires the whole remaining value to be digits, rejecting anything else. An RFC-strict intermediary that rejects or reframes a chunk-size line with a non-extension tail, on a connection where Mint accepts it, yields a framing disagreement about chunk length and, through the terminating chunk, about where the message ends.

Proof of concept

1. Start a loopback TCP server that serves one HTTP/1.1 200 OK response with transfer-encoding: chunked and controls the chunk-size line byte for byte.
2. Connect with Mint.HTTP1 (mint 1.10.0 from Hex), send a request and stream the response.
3. Positive controls: chunk-size lines +5, Z5 and 00000000000000005 are refused with :invalid_chunk_size, confirming the build carries the earlier chunk-size fixes.
4. Baseline: 5 and 5;name=value are accepted with body hello.
5. Finding: 5ZZZZZ, 5 anything at all, 5<TAB>foo, 5 9 and 5}~! are each accepted as chunk size 5 with body hello.
6. Terminator: 0ZZZZ and 0 9 in place of the final 0 chunk are accepted and end the body.
7. Contrast: Content-Length: +5, Content-Length: 5ZZZ and Content-Length: 5 9 are refused with :invalid_content_length_header in the same run.

The reporter ran this on Elixir 1.18 / OTP 27 and Elixir 1.18.4 / OTP 28 with identical results.

Impact

A malicious or attacker-influenced HTTP/1 origin behind an RFC-strict intermediary can make the intermediary and the Mint client disagree on chunk boundaries and on where the response body ends. On a pooled keep-alive connection that disagreement lets bytes from one response be attributed to the next, poisoning the responses returned to unrelated requests that share the connection.

Configurations

Exploitation requires a deployment topology in which an RFC-strict HTTP/1 intermediary (proxy, load balancer, or WAF) sits between the Mint client and the attacker-influenced origin, and HTTP/1 connections between the client and the intermediary are reused across requests (keep-alive with connection pooling). Mint clients that talk directly to an origin without an intermediary, or that do not reuse connections, are not exploitable for response-queue poisoning even if the vulnerable parsing behavior is present.

Summary

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

Two HTTP/1 response-parser states accumulate server data without any cap. In lib/mint/http1.ex, decode_status_line/4 stores the unconsumed data in conn.buffer when the status line is incomplete, and decode_body/5 does the same for an unterminated chunk-extension line. Both wait for a CRLF the server never has to send, and conn.buffer is prepended to every subsequent socket message. The :max_header_list_size budget is wired only into decode_headers/5 and decode_trailer_headers/4, so neither of these states is covered by it. A malicious server, or one reached through an attacker-controlled redirect or a fetched URL, streams bytes indefinitely until the BEAM node is killed by the operating system out-of-memory handler. The chunk-extension variant is reached after a valid status line and a complete, valid header section, so an intermediary inspecting only headers sees an ordinary 200 response.

This issue affects mint: from 0.1.0 before 1.10.0.

Summary

Inconsistent interpretation of HTTP requests (HTTP response smuggling) vulnerability in elixir-mint mint allows a malicious HTTP/1 server to desynchronize a strict intermediary and the Mint client on the same pooled connection, enabling response-queue poisoning against subsequent requests that share the connection.

The Mint.HTTP1.decode_body/5 function in lib/mint/http1.ex parses the chunk-size line of a Transfer-Encoding: chunked response with Integer.parse(data, 16). RFC 7230 defines chunk-size = 1*HEXDIG and forbids any sign prefix, but Integer.parse/2 accepts an optional leading + or -. A chunk-size line of +5 is accepted as a five-byte chunk; lines of +0 and -0 are accepted as the terminating zero-length chunk and end the message body early.

An RFC-strict intermediary in the response path rejects these forms, so the intermediary and the Mint client disagree on where one response ends and the next begins. On a pooled keep-alive connection, an attacker-influenced origin can inject bytes that the client attributes to the next legitimate response on the same connection, poisoning the response queue and corrupting the responses returned to unrelated in-flight requests.

This issue affects mint: from 0.1.0 before 1.9.3.

Configurations

Exploitation requires a deployment topology in which an RFC-strict HTTP/1 intermediary (proxy, load balancer, or WAF) sits between the Mint client and the attacker-influenced origin, and HTTP/1 connections between the client and the intermediary are reused across requests (keep-alive with connection pooling). Mint clients that talk directly to an origin without an intermediary, or that do not reuse connections, are not exploitable for response-queue poisoning even if the vulnerable parsing behavior is present.

Summary

Allocation of resources without limits vulnerability in elixir-mint mint allows a remote HTTP/2 server to exhaust memory on the client host and cause a denial of service.

The Mint.HTTP2.handle_continuation/3 function in lib/mint/http2.ex accumulates the header-block fragment carried by each HTTP/2 CONTINUATION frame into a growing conn.headers_being_processed nesting, one level deeper per frame, and only releases it when a frame with the END_HEADERS flag arrives. The only guard on this accumulator is Mint.HTTP2.assert_header_block_within_max_size/2, which sums the byte size of the fragments received so far. Because a CONTINUATION frame is permitted by the protocol to carry a zero-length payload, an unbounded chain of zero-length CONTINUATION frames adds no bytes to the running total, never trips the size cap, and never emits END_HEADERS, yet each frame still nests the accumulator one level deeper.

A malicious HTTP/2 server (reachable directly, via an attacker-controlled redirect, via SSRF, or via a man-in-the-middle) can open a stream by sending a HEADERS frame without END_HEADERS and then stream zero-length CONTINUATION frames indefinitely. Client memory grows one cons cell per frame received; sustained bandwidth from the peer drives the BEAM node running the Mint client to memory exhaustion and eventual out-of-memory termination.

This issue affects mint: from 0.1.0 before 1.9.2.