Summary
Mint (Mint.HTTP1) contains an unbounded-memory denial of service in its chunked transfer-encoding decoder. When decoding a chunked response body, Mint buffers every partial fragment of the current chunk in memory and does not release it to the caller until the full declared chunk length has arrived. The chunk size is read straight from the server and parsed with no upper bound, so a malicious or compromised server can announce one enormous chunk and then dribble bytes without ever completing it, forcing the client to accumulate the whole (never-finished) chunk in memory. Any unauthenticated remote server that a Mint client can be steered to reach (via a redirect, SSRF, or webhook fetch) can trigger it.
Details
The bug lives in Mint.HTTP1's chunked-body decoder in lib/mint/http1.ex, primarily decode_body/5 and its helper add_body_to_buffer/2.
1. Unbounded chunk-size parsing. The chunk size line is parsed with Integer.parse(data, 16) with no maximum. A server can declare a chunk of arbitrary size, e.g. a size line of 7FFFFFFF (~2 GiB).
2. Buffer-until-complete decoding. For a chunk of declared size, the decoder computes new_size = size - byte_size(data) and, while the chunk is not yet complete (new_size > 0), appends every received fragment to request.data_buffer via add_body_to_buffer/2 (an unbounded iolist). Data is only emitted to the caller once the full declared length has been received, when add_body/3 collapses and flushes the accumulated buffer. Because the chunk never completes, the buffer grows without bound and no {:data, ...} responses are ever produced.
3. Streaming contract bypass. This is worse than a plain large-body issue. The content-length path emits each received packet immediately via add_body/3, so a caller that safely streams large content-length bodies still gets forced to buffer the entire chunk in the chunked case. The caller cannot observe or bound the growth because no data responses are emitted at all until the chunk finishes.
The same "no size limit on server-controlled data" root cause also affects the unbounded header count in decode_headers/5 and the unbounded chunk-size line buffer, but the chunked-body path is the most concrete because it bypasses streaming entirely.
PoC
- Stand up an attacker-controlled TCP server that accepts a Mint connection and replies with
HTTP/1.1 200 OK, Transfer-Encoding: chunked, then a chunk size line of 7FFFFFFF\r\n (~2 GiB).
- Dribble body bytes (e.g. 64 KiB packets) continuously without ever sending the chunk terminator, and hold the connection open.
- Point a normal Mint client at the server (
Mint.HTTP.connect + Mint.HTTP.request) and drain the socket via Mint.HTTP.recv.
- Observe that zero
{:data, ...} responses are emitted to the caller while process memory grows in lockstep with the dribbled bytes (measured ~506 MiB buffered for 500 MiB dribbled), climbing until out-of-memory.
Impact
A remote attacker who controls or has compromised a server that a Mint client connects to can drive the client's memory arbitrarily high and trigger an out-of-memory condition, crashing the application. No client-side authentication is required, and applications that follow redirects, fetch user-supplied URLs (SSRF), or process webhooks are the most exposed; callers that otherwise stream large bodies safely gain no protection.
References
PJUllrich Reporter
maennchen Analyst
whatyouhide Remediation developer
ericmj Analyst
Summary
Mint (
Mint.HTTP1) contains an unbounded-memory denial of service in its chunked transfer-encoding decoder. When decoding achunkedresponse body, Mint buffers every partial fragment of the current chunk in memory and does not release it to the caller until the full declared chunk length has arrived. The chunk size is read straight from the server and parsed with no upper bound, so a malicious or compromised server can announce one enormous chunk and then dribble bytes without ever completing it, forcing the client to accumulate the whole (never-finished) chunk in memory. Any unauthenticated remote server that a Mint client can be steered to reach (via a redirect, SSRF, or webhook fetch) can trigger it.Details
The bug lives in
Mint.HTTP1's chunked-body decoder inlib/mint/http1.ex, primarilydecode_body/5and its helperadd_body_to_buffer/2.1. Unbounded chunk-size parsing. The chunk size line is parsed with
Integer.parse(data, 16)with no maximum. A server can declare a chunk of arbitrary size, e.g. a size line of7FFFFFFF(~2 GiB).2. Buffer-until-complete decoding. For a chunk of declared
size, the decoder computesnew_size = size - byte_size(data)and, while the chunk is not yet complete (new_size > 0), appends every received fragment torequest.data_bufferviaadd_body_to_buffer/2(an unbounded iolist). Data is only emitted to the caller once the full declared length has been received, whenadd_body/3collapses and flushes the accumulated buffer. Because the chunk never completes, the buffer grows without bound and no{:data, ...}responses are ever produced.3. Streaming contract bypass. This is worse than a plain large-body issue. The
content-lengthpath emits each received packet immediately viaadd_body/3, so a caller that safely streams largecontent-lengthbodies still gets forced to buffer the entire chunk in thechunkedcase. The caller cannot observe or bound the growth because no data responses are emitted at all until the chunk finishes.The same "no size limit on server-controlled data" root cause also affects the unbounded header count in
decode_headers/5and the unbounded chunk-size line buffer, but the chunked-body path is the most concrete because it bypasses streaming entirely.PoC
HTTP/1.1 200 OK,Transfer-Encoding: chunked, then a chunk size line of7FFFFFFF\r\n(~2 GiB).Mint.HTTP.connect+Mint.HTTP.request) and drain the socket viaMint.HTTP.recv.{:data, ...}responses are emitted to the caller while process memory grows in lockstep with the dribbled bytes (measured ~506 MiB buffered for 500 MiB dribbled), climbing until out-of-memory.Impact
A remote attacker who controls or has compromised a server that a Mint client connects to can drive the client's memory arbitrarily high and trigger an out-of-memory condition, crashing the application. No client-side authentication is required, and applications that follow redirects, fetch user-supplied URLs (SSRF), or process webhooks are the most exposed; callers that otherwise stream large bodies safely gain no protection.
References