Unvalidated chunk-size line tail in Mint HTTP/1 client enables response smuggling against strict intermediaries on pooled connections

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.

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.

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.

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.