CVE-2026-48596: Improper Neutralization of CRLF Sequences in Elixir Tesla Multipart HTTP Client

The Elixir library tesla is a highly customizable HTTP client that provides an abstract interface over multiple adapters, such as Hackney, Mint, Ibrowse, and HTTPC. One of the key modules provided by the library is Tesla.Multipart, which facilitates the creation and encoding of multipart/form-data requests. This module exposes functions to define boundaries, add form fields, and configure content-type parameters.\n\nCVE-2026-48596 is classified under CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting'). The flaw occurs when user-provided or dynamically generated strings are supplied to the Tesla.Multipart.add_content_type_param/2 function. These parameters are appended to an internal list and subsequently formatted into the single Content-Type header without neutralizing Carriage Return (\r) and Line Feed (\n) characters.\n\nThe vulnerability allows an attacker to manipulate the generated headers when the HTTP adapter serializes the request to a raw TCP socket. Because the underlying adapters trust the header values returned by Tesla.Multipart.headers/1, they write the raw input to the network, resulting in HTTP request splitting or arbitrary header injection.

The root cause of CVE-2026-48596 resides in the absence of validation in the Tesla.Multipart.add_content_type_param/2 function and the raw formatting logic in Tesla.Multipart.headers/1. In versions prior to 1.18.3, Tesla.Multipart defined add_content_type_param/2 as a simple list concatenation wrapper. It accepted any arbitrary binary value and appended it directly to the internal content_type_params field without validating its characters against the token definitions of RFC 7230 and RFC 7231.\n\nDuring the generation of headers, Tesla.Multipart.headers/1 extracts the multipart boundary and the configured content-type parameters. It combines them into a list and executes Enum.join(params, "; ") to build a single string for the Content-Type header value. This string is then passed downstream to the configured adapter.\n\nBecause there is no sanitization or enforcement of valid character ranges, any injected carriage return (\r) and line feed (\n) characters are embedded directly into the header value string. When the underlying adapter formats this string into raw HTTP bytes, the CRLF sequence acts as an HTTP header delimiter, enabling the injection of new headers or the premature termination of the headers section.

To understand the flow, we examine the vulnerable implementation in lib/tesla/multipart.ex prior to version 1.18.3:\n\nelixir\n# Vulnerable implementation of Tesla.Multipart\ndefstruct [\n parts: [],\n boundary: nil,\n content_type_params: []\n]\n\n@spec add_content_type_param(t, String.t) :: t\ndef add_content_type_param(%__MODULE__{} = mp, param) do\n %{mp | content_type_params: mp.content_type_params ++ [param]}\nend\n\n@spec headers(t) :: Keyword.t\ndef headers(%__MODULE__{boundary: boundary, content_type_params: params}) do\n ct_params = ([\"boundary=\#{boundary}\"] ++ params) |> Enum.join(\"; \")\n [{:\"Content-Type\", \"multipart/form-data; \#{ct_params}\"}]\nend\n\n\nThe vulnerability is resolved in version 1.18.3 by implementing RFC-compliant validation guards and assertion functions. The patched implementation introduces strict checks on the allowed character set for parameters:\n\nelixir\n# Patched implementation in lib/tesla/multipart.ex\n@token_specials ~c\"!#$%&'*+-.^_`|~\"\n\ndefguardp is_tchar(c)\n when c in ?A..?Z or\n c in ?a..?z or\n c in ?0..?9 or\n c in @token_specials\n\ndefguardp is_field_vchar(c) when c == ?\t or (c >= 32 and c != 127)\n\n@spec assert_content_type_param!(any) :: :ok | no_return\ndefp assert_content_type_param!(value) when is_binary(value) and byte_size(value) > 0 do\n do_assert_ctp!(value, value)\nend\n\ndefp do_assert_ctp!(_orig, <<>>), do: :ok\n\ndefp do_assert_ctp!(orig, <<c, rest::binary>>) when is_field_vchar(c) and c != ?; do\n do_assert_ctp!(orig, rest)\nend\n\ndefp do_assert_ctp!(orig, <<c, _::binary>>) do\n raise ArgumentError,\n \"content-type param must not contain CTLs, DEL, or `;` per RFC 7231, \" <>\n \"got: \#{inspect(orig)} (invalid character: \#{inspect(<<c>>)})\"\nend\n\n\nThe addition of these guard clauses prevents characters like \r, \n, and ; from being stored in the content_type_params list. If any invalid character is encountered, the code raises an ArgumentError immediately, halting the request generation before it can reach the network.

An attacker can exploit this vulnerability if they control any string that is forwarded to add_content_type_param/2. For instance, in applications where users are allowed to specify custom file encodings, charsets, or boundary attributes, the untrusted input can be embedded in the multipart header.\n\nThe core of the exploit relies on the injection of \r\n sequences (CRLF). When the raw TCP socket writer of the HTTP client serializes the header, it interprets the CRLF as the physical end of the current header. Any content following the CRLF is parsed as a new header. Below is a conceptual representation of the network translation:\n\nmermaid\ngraph LR\n A[\"User Input: utf-8\\r\\nSmuggled-Header: True\"] --> B[\"Tesla.Multipart.add_content_type_param/2\"]\n B --> C[\"Tesla.Multipart.headers/1 joins with '; '\"]\n C --> D[\"Content-Type: multipart/form-data; boundary=xyz; charset=utf-8\\r\\nSmuggled-Header: True\"]\n D --> E[\"HTTP Adapter serializes to Raw Socket\"]\n E --> F[\"Socket Stream interprets \\r\\n as a physical line break\"]\n\n\nBy injecting multiple header lines, an attacker can overwrite existing headers (such as Host or Authorization) or insert arbitrary headers that alter the request's context, such as X-Forwarded-For or custom authentication bypass headers.

The impact of successful exploitation is moderate to critical, depending on the role of the client in the network architecture. The vulnerability allows for HTTP Header Injection and HTTP Request Splitting. This can result in several threat scenarios, such as Server-Side Request Forgery (SSRF) bypasses where security filters rely on proxy headers, Cache Poisoning if the client communicates with an intermediary reverse proxy, and session hijacking if authorization headers are manipulated.\n\nIn a CVSS v4.0 assessment, the Erlang Ecosystem Foundation assigned a score of 2.1 (Low). This is primarily because the vulnerability resides in a library dependency, requiring local application-level integration factors to expose the vulnerability to remote inputs. However, if an application directly exposes the parameter input to the web, the operational impact can escalate to a high severity, potentially leading to complete authorization bypasses or request smuggling.

The primary remediation strategy is to upgrade the tesla library dependency to version 1.18.3 or later. This version enforces the RFC 7231 grammatical validations and prevents the injection at the source. If immediate upgrading is not feasible, developers must implement strict validation on all inputs passed to add_content_type_param/2.\n\nelixir\n# Temporary Sanitization Workaround\ndefmodule SanitizedTesla do\n def add_content_type_param(multipart, param) do\n if String.contains?(param, [\"\\r\", \"\\n\", \";\"]) do\n raise ArgumentError, \"Dangerous characters detected\"\n else\n Tesla.Multipart.add_content_type_param(multipart, param)\n end\n end\nend\n\n\nFurthermore, organizations should run automated dependency analysis tools and implement static analysis checks to detect patterns where non-static variables are supplied directly to multipart configuration parameters.