EEF-CVE-2026-94194

## 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.11.0.

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