CVE-2026-48861: HTTP Request Splitting and Smuggling via Method Parameter CRLF Injection in Elixir Mint

The vulnerability is located in Mint, a widely used low-level HTTP client library for the Elixir programming language. The component exposes a client-side attack surface when application code acts as a proxy, webhook forwarder, or API gateway. When such applications accept user-controlled strings to define outbound HTTP connection parameters, they pass the untrusted inputs directly to Mint's internal serialization layers.

In vulnerable versions, Mint fails to validate or neutralize carriage return (CR) and line feed (LF) characters inside the HTTP method parameter. This failure violates RFC 9110 specifications, which mandate that HTTP methods consist only of valid token characters. Consequently, an attacker can submit a crafted HTTP method containing embedded CRLF characters to manipulate the client's output stream.

The resulting injection splits the outbound HTTP stream into multiple distinct requests. From the perspective of downstream proxy servers, reverse proxies, or load balancers, the single TCP connection appears to contain multiple independent pipelined queries. This behavior facilitates a range of attacks including unauthorized lateral movement, server-side request forgery (SSRF), and cache poisoning.

The root cause of the vulnerability resides in the HTTP/1 request-line compilation logic within Mint. According to the HTTP/1.1 specification, a standard request-line must strictly conform to a defined structure consisting of the method, a single space, the request target, another single space, the protocol version, and a terminating CRLF sequence.

In vulnerable versions of Mint, specifically inside the lib/mint/http1/request.ex module, the encode_request_line/2 function compiles the request-line by directly concatenating the user-supplied method and target parameters into an iolist. This implementation is completed without checking if either variable contains forbidden control characters, spaces, or protocol delimiter bytes.

While Mint 1.7.0 introduced the helper validate_request_target/2 to sanitize target URIs and prevent CRLF injections via the path or query string, the library left the HTTP method parameter completely unvalidated. The developers assumed that applications would only supply static, hardcoded method names like "GET" or "POST" to the client library.

However, when an application dynamically accepts and forwards an HTTP method from an external source, this design assumption fails. Because there is no token validation on the method string, any control sequences inserted by the attacker pass unaltered into the network socket. The receiving server parses these control characters as structural boundaries, altering the intended request structure.

An analysis of the vulnerable codebase in lib/mint/http1/request.ex reveals the following serialization logic:

defp encode_request_line(method, target) do
  [method, ?\s, target, " HTTP/1.1\r\n"]
end

This implementation directly interpolates the method argument into the character stream. The official patch (fad091454cbb7449b19edb8e1fee12ca7cf28c3a) addresses this weakness by introducing a strict whitelist check on the HTTP method argument before compiling the request-line.

# lib/mint/http1/request.ex
def encode(method, target, headers, body) do
+   validate_method!(method)
+
    body = [
      encode_request_line(method, target),
      encode_headers(headers),

The fix is implemented within the new private function validate_method!/1, which loops through each byte of the method parameter and validates it against the is_tchar/1 macro imported from Mint.HTTP1.Parse:

+  defp validate_method!(method) do
+    _ =
+      for <<char <- method>> do
+        unless is_tchar(char) do
+          throw({:mint, {:invalid_request_method, method}})
+        end
+      end
+
+    :ok
+  end

Because the is_tchar/1 macro restricts allowed bytes to the exact set of token characters permitted by RFC 9110, control characters such as tabs, spaces, carriage returns, and line feeds are rejected. If an illegal byte is encountered, the library throws an exception which is subsequently translated into an invalid request method error. This patch prevents the compilation of malformed request lines and successfully mitigates the CRLF injection vector.

Exploitation requires an application that acts as an intermediary, receiving input from an untrusted source and forwarding it to Mint without sanitization. An attacker constructs an HTTP request targeting the proxy application, supplying a malicious payload within the parameter mapped to the outbound HTTP method.

An attacker may transmit a payload where the method argument contains the following sequence:

GET / HTTP/1.1\r\nHost: internal-service.local\r\n\r\nGET /admin/delete_user?id=1 HTTP/1.1\r\nHost: internal-service.local\r\nIgnore-Header:

When Mint processes this input, it writes the concatenated byte stream to the connection. The resulting TCP payload is formatted as follows:

GET / HTTP/1.1
Host: internal-service.local
 
GET /admin/delete_user?id=1 HTTP/1.1
Host: internal-service.local
Ignore-Header:  /api/v1/resource HTTP/1.1

Upon receiving this stream, the downstream server parses the first section as a legitimate, benign request. Due to the double CRLF (\r\n\r\n) sequence, the parser treats the subsequent bytes as a second, separate pipelined request. The final, dangling fragment is appended to the smuggled request headers, completing the injection. This technique successfully bypasses security controls that are only applied to the outer request wrapper.

The concrete impact of CVE-2026-48861 is determined by the downstream network architecture and the authorization model of the environment. In environments where reverse proxies or load balancers cache content, attackers can exploit request splitting to inject arbitrary cached responses. This cache poisoning vector can result in the distribution of malicious content to other, unrelated users of the application.

In microservice architectures, this flaw facilitates lateral movement and security bypasses. Because the smuggled request originates from the internal IP address of the Elixir gateway application, the target service processes the request under the assumption that it comes from a trusted internal source. This trust allows the attacker to execute privileged actions or access sensitive endpoints without authentication.

The vulnerability is assigned a CVSS v4.0 base score of 2.1, reflecting a low severity under isolated circumstances. This low score is due to the prerequisite that application developers must actively design a proxy pattern that accepts dynamic, user-controlled HTTP methods. However, in deployments that implement such patterns, the vulnerability presents a significant security risk.

At present, the vulnerability has an EPSS score of 0.00166, indicating a low probability of active exploitation in the wild. It is not currently included in the CISA Known Exploited Vulnerabilities catalog. Nevertheless, organizations running vulnerable configurations should remediate the issue to prevent potential exploitation.

The primary and recommended mitigation for this vulnerability is upgrading the mint package to version 1.9.0 or higher. This update introduces the necessary HTTP method token validation checks inside the request compilation process, neutralizing the CRLF injection vector at the library boundary.

If upgrading the dependency is not immediately possible, developers must implement application-level input validation. Any user-supplied parameter destined for the HTTP method field must be validated against a strict whitelist of standard HTTP methods. This validation can be performed in the application controller layer:

defp validate_http_method(method) when method in ["GET", "POST", "PUT", "DELETE", "PATCH", "HEAD", "OPTIONS"] do
  {:ok, method}
end
defp validate_http_method(_invalid_method), do: {:error, :invalid_method}

Security teams can detect vulnerable instances of Mint by performing dependency scans on their Elixir codebases. Tools such as mix hex.audit or static application security testing (SAST) utilities like Sobelow can flag outdated package dependencies.

Additionally, network-level detection can be implemented via Web Application Firewalls (WAFs) or Intrusion Detection Systems (IDS). Rules should be configured to detect and drop inbound requests containing carriage returns or line feeds within application parameter values designed for downstream proxy routing.