mint

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

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

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

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

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

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

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

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

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

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