Andrea Leopardi

An unauthenticated remote attacker can cause a crash of the decoding process by providing a deeply nested JSON document. This occurs when an application decodes attacker-supplied JSON into a schema containing a self-referential or cyclic message type using the functions `Protobuf.JSON.decode/3`, `Protobuf.JSON.decode!/3`, or `Protobuf.JSON.from decoded/3`. In `lib/protobuf/json/decode.ex`, the `embedded-message` clause of the `decode singular/3` function recurses into `internal from json data/3` for each nesting level without incrementing or verifying the decoder's depth counter. While the `increase depth and maybe throw/1` guard exists, it only applies to `Google.Protobuf.ListValue` and `Google.Protobuf.Struct` clauses, rendering the `recursion limit` option ineffective for user-defined message types. Consequently, each nesting level allocates a stack frame and heap objects, allowing a sufficiently deep document to exhaust the memory of the decoding process and crash it. If the BEAM `max heap size` process flag is set to unlimited, concurrent requests may exhaust the memory of the entire node.

A resource allocation issue allows a malicious HTTP/2 server to force a client to buffer up to approximately 16 MiB per connection in frames that should be rejected, leading to excessive client memory consumption. This occurs because the function `decode next/2` in `lib/mint/http2/frame.ex` only validates the frame against the `max frame size` variable after the entire declared payload has been received. Until the payload is complete, the system returns `:more`, causing `Mint.HTTP2` to store all received bytes in the connection buffer. A server can declare a frame length up to 16,777,215 bytes and withhold the final byte to maintain this buffer for as long as the connection remains open. This can lead to memory exhaustion for clients maintaining numerous connections to untrusted origins, such as proxies, crawlers, or webhook senders.

A malicious HTTP/2 server can cause a denial of service by exhausting memory on the client host. The issue occurs because `Mint.HTTP2` only enforces the `max header list size` setting on the compressed size of an inbound header block, rather than the decoded header list as required by RFC 9113. An attacker can use HPACK indexed fields to create a small compressed block that expands into a very large decoded list. Specifically, the `join cookie headers/1` function in `lib/mint/http2.ex` copies every `cookie` value of a response into a single new binary, which can lead to the allocation of approximately 1 GB for a single response under default settings. This memory exhaustion can crash the process owning the connection or the entire BEAM virtual machine.

An inconsistent interpretation of HTTP requests, known as HTTP Request/Response Smuggling, allows a malicious HTTP/1 server to desynchronize a strict intermediary and the Mint client on a pooled connection. This can lead to response-queue poisoning, where bytes from one response are attributed to subsequent requests sharing the same connection. The issue occurs because the `chunk size/1` function in `Mint.HTTP1.Parse` stops at the first non-hexadecimal byte of a chunked response's chunk-size line and returns the remainder unexamined. Subsequently, the `decode body/5` function in `Mint.HTTP1` discards all bytes up to the CRLF using `Parse.ignore until crlf/1`. This results in the acceptance of hex digits followed by arbitrary bytes, whereas RFC 9112 only permits chunk extensions introduced by a `;`. Consequently, an RFC-strict intermediary may reject a line that Mint accepts, causing a disagreement on chunk boundaries and the end of the response body.

An inefficient algorithmic complexity issue allows a remote HTTP server to exhaust CPU resources on the client host, leading to a denial of service. The `parse hex prefix/2` function in `lib/mint/http1/parse.ex` processes hex digits of a chunked response's chunk-size field using an arbitrary-precision accumulator without limiting the digit count. This results in O(N squared) time complexity for processing N digits. Additionally, the `handle data/2` function prepends the `conn.buffer` and re-parses from the beginning for every socket message, which can be exploited by a server sending digits in small packets to repeatedly trigger the high CPU cost. This state is reached after a valid status line and header section, potentially bypassing intermediaries that only inspect headers.

A remote HTTP server can cause a denial of service by exhausting memory on the client host. This occurs because two HTTP/1 response-parser states accumulate server data without limits. Specifically, the `decode status line/4` function stores unconsumed data in `conn.buffer` when the status line is incomplete, and the `decode body/5` function does the same for an unterminated chunk-extension line. Both functions wait for a CRLF (Carriage Return Line Feed) sequence that a malicious server may never send, causing `conn.buffer` to be prepended to every subsequent socket message. While a budget exists via `:max header list size`, it only applies to `decode headers/5` and `decode trailer headers/4`, leaving these two states unprotected. An attacker can stream bytes indefinitely until the BEAM node is terminated by the operating system's out-of-memory handler. In the case of chunk-extensions, the attack occurs after a valid status line and header section, potentially bypassing intermediaries that only inspect headers.

An HTTP response smuggling issue exists due to the inconsistent interpretation of HTTP requests. A malicious HTTP/1 server can desynchronize a strict intermediary and the Mint client on a pooled connection, leading to response-queue poisoning for subsequent requests sharing that connection. The `decode body()` function in `lib/mint/http1.ex` uses `Integer.parse(data, 16)` to parse the chunk-size line of a Transfer-Encoding: chunked response. While RFC 7230 forbids sign prefixes for chunk-size, `Integer.parse/2` accepts leading + or - signs. Consequently, a chunk-size line of +5 is treated as a five-byte chunk, and +0 or -0 are treated as terminating zero-length chunks, ending the message body prematurely. An RFC-strict intermediary rejects these forms, causing a disagreement on response boundaries. On pooled keep-alive connections, an attacker-influenced origin can inject bytes that the client attributes to the next legitimate response, corrupting responses for unrelated in-flight requests. This requires a topology where an RFC-strict HTTP/1 intermediary (such as a proxy, load balancer, or WAF) is positioned between the Mint client and the origin, and connections are reused.

A remote HTTP server can cause a denial of service by exhausting memory on the client host. The `Mint.HTTP1.decode headers/5` and `Mint.HTTP1.decode trailer headers/4` functions accumulate parsed response headers and chunked-trailer fields into a per-request list `request.headers buffer` that persists across TCP segments. Because there is no cap on the number of headers or total bytes, and the `:erlang.decode packet(:httph bin, binary, [])` parser is used with unlimited default size limits, a malicious server can stream header or trailer lines indefinitely without sending the terminating blank line. This causes the connection state to grow without bound until the BEAM node is terminated by the operating system's out-of-memory handler.

A remote HTTP/2 server can cause memory exhaustion and a denial of service on the client host. The `handle continuation/3` function in `lib/mint/http2.ex` accumulates header-block fragments from HTTP/2 CONTINUATION frames into a nesting structure that only releases upon receiving a frame with the END HEADERS flag. While there is a size limit check via `assert header block within max size/2`, the protocol allows CONTINUATION frames to have zero-length payloads. An attacker can send an unbounded chain of these zero-length frames, which bypasses the size cap and continuously increases memory consumption by adding one cons cell per frame, eventually leading to out-of-memory termination of the BEAM node.

A denial of service issue exists in the `Mint.HTTP1` module. When decoding a chunked HTTP response body, the software accumulates partial fragments in the `data buffer` (an unbounded iolist) using the `add body to buffer/2` function and does not emit data until the full declared chunk length is received. Because the chunk size is parsed from the server without an upper bound, a malicious server can specify an enormous chunk size and send bytes slowly. This forces the client to buffer data indefinitely, potentially leading to an out-of-memory condition. This can be triggered when a client follows redirects, fetches user-supplied URLs, or processes webhooks. The issue is associated with the `decode body/5` function in the `lib/mint/http1.ex` file.

An inefficient algorithmic complexity issue exists during the decoding of HPACK variable-length integers. The `Elixir.HPAX.Types`:decode remaining integer/3 function, accessed via the `Elixir.HPAX`:decode/2 entry point, does not impose an upper bound on the decoded value or the number of continuation octets. Since BEAM integers use arbitrary precision, a sequence of continuation octets creates an O(N)-bit bignum, resulting in a superlinear decoding cost of approximately O(N^2). An unauthenticated attacker can exploit this by sending a small HTTP/2 header block that consumes excessive CPU and transient memory, leading to a denial-of-service amplification.