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.

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.

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.

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.

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.

Stack-based Buffer Overflow vulnerability in Erlang OTP (erl_interface) allows Stack-based Buffer Overflow. This vulnerability is associated with program file lib/erl_interface/src/misc/ei_printterm.c and program routine ei_s_print_term. The C function ei_s_print_term uses an internal 2000-character stack buffer to format terms. When called with an encoded Erlang term containing a very large integer (encoded representation exceeding 2000 characters), the buffer overflows. The overflow bytes are restricted to the ASCII values of 0-9 and A-F, which limits exploitation to Denial of Service. The companion function ei_print_term, which prints directly to a FILE instead of a memory buffer, does not contain this bug. This issue affects OTP from OTP 17.0 before 27.3.4.13, 28.5.0.2 and 29.0.2, corresponding to erl_interface from 3.7.16 before 5.5.2.1, 5.7.0.1 and 5.8.1.

Sensitive Data Exposure vulnerability in Erlang OTP inets (httpc_response module) allows Retrieve Embedded Sensitive Data. The httpc client forwards the Authorization and Proxy-Authorization request headers to redirect targets without checking whether the redirect crosses an origin boundary. httpc_response:redirect/2 constructs the redirected request by updating only the host field of the header record; all other fields (including authorization and proxy_authorization) are copied verbatim. The redirect target host is never compared against the original host. autoredirect defaults to true, so this affects all httpc callers that do not explicitly disable automatic redirects. An attacker who controls a server that the victim contacts via httpc can issue a cross-origin 3xx redirect to a server they also control. The Authorization header (including Basic credentials derived from URL userinfo via httpc_request:handle_user_info/2) is forwarded to the redirect target, allowing credential theft. The same applies to the Proxy-Authorization header. This vulnerability is associated with program files lib/inets/src/http_client/httpc_response.erl. This issue affects OTP from 17.0 before 29.0.2, 28.5.0.2 and 27.3.4.13 corresponding to inets from 5.10 before 9.7.1, 9.6.2.2 and 9.3.2.6.

Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') vulnerability in elixir-mint Mint allows attacker-controlled HTTP/1 servers to desynchronise response framing on shared connections. Mint's HTTP/1 Content-Length parser, Mint.HTTP1.Parse.content_length_header/1 in lib/mint/http1/parse.ex, parses the header value with Integer.parse/1, which accepts an optional + or - sign prefix. The length >= 0 guard rejects negatives, but inputs such as +0 or +123 are returned as valid lengths. RFC 7230 specifies Content-Length = 1*DIGIT, with no sign character permitted. A fronting proxy or load balancer that strictly enforces the grammar will reject or reframe a header like Content-Length: +0, while Mint silently treats it as zero. When Mint reuses the socket (keep-alive, pipelining, or any pooled connection shared across requesters), the parser disagreement is a response-smuggling primitive: the proxy delimits the body one way, Mint another, and bytes from one response get attributed to the next. Where the same Mint connection is shared across trust boundaries, an attacker-controlled upstream can leak bytes into a different consumer's response stream. This issue affects mint: from 0.1.0 before 1.9.0.

Allocation of Resources Without Limits or Throttling vulnerability in elixir-mint Mint allows attacker-controlled HTTP/2 servers to exhaust memory in a Mint client via PUSH_PROMISE flooding. In lib/mint/http2.ex, Mint.HTTP2.decode_push_promise_headers_and_add_response/5 inserts a :reserved_remote entry into conn.streams for every promised stream ID. The neighbouring Mint.HTTP2.assert_valid_promised_stream_id/2 only verifies 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, so a server that emits PUSH_PROMISE frames and withholds the matching HEADERS never trips that check. HTTP/2 server push is accepted by default (client_settings.enable_push defaults to true). A single long-lived HTTP/2 connection to a hostile server lets that server pin one conn.streams entry per PUSH_PROMISE frame it sends, with no upper bound, until the client process runs out of memory. This issue affects mint: from 0.2.0 before 1.9.0.

Improper Neutralization of CRLF Sequences ('CRLF Injection') vulnerability in elixir-mint Mint allows HTTP Request Splitting and HTTP Request Smuggling. In lib/mint/http1/request.ex, the encode_request_line/2 function splices the caller-supplied method and target arguments directly into the HTTP/1 request line without any character validation: [method, ?\s, target, " HTTP/1.1\r\n"]. An application that forwards attacker-controlled input as the HTTP method or target to Mint.HTTP.request/5 is therefore exposed to request-line CRLF injection: the attacker can terminate the request line early, inject arbitrary headers, and smuggle an entirely separate pipelined HTTP request onto the same TCP connection. Mint 1.7.0 introduced validate_request_target/2, which rejects CRLF and other control characters in the target by default and closes the path/query vector unless the caller opts out via skip_target_validation: true. The method field remains unvalidated, so the method-based injection is exploitable under the default Mint configuration on all versions. This issue affects mint: from 0.1.0 before 1.9.0.