CVE-2026-48596: Tesla Elixir HTTP Header Injection Flaw

CVE-2026-48596 Overview

CVE-2026-48596 is an HTTP header injection vulnerability in the elixir-tesla HTTP client library for Elixir. The flaw resides in Tesla.Multipart.add_content_type_param/2, which appends caller-supplied strings to the multipart content_type_params list without validating for carriage return (\r) or line feed (\n) characters. When Tesla.Multipart.headers/1 joins these parameters into the outbound Content-Type header, embedded CRLF sequences split the header line and allow arbitrary header injection. Applications forwarding untrusted input such as user-supplied charsets or parameter strings into the affected function are exposed. The issue affects tesla from version 0.8.0 before 1.18.3 and maps to CWE-113.

Critical Impact

Attackers controlling input passed to add_content_type_param/2 can inject arbitrary HTTP headers into outbound requests, enabling request smuggling, cache poisoning, or downstream integrity issues against connected services.

Affected Products

• elixir-tesla tesla library versions 0.8.0 through 1.18.2
• Elixir applications using Tesla.Multipart.add_content_type_param/2 with untrusted input
• Downstream services receiving HTTP requests generated through the vulnerable multipart code path

Discovery Timeline

• 2026-06-02 - CVE-2026-48596 published to NVD
• 2026-06-03 - Last updated in NVD database

Technical Details for CVE-2026-48596

Vulnerability Analysis

The vulnerability is a classic HTTP Request/Response Splitting issue caused by missing neutralization of CRLF sequences in user-controlled input. Tesla is a widely used HTTP client library in the Elixir ecosystem, and its multipart support builds the Content-Type header by concatenating parameters provided through add_content_type_param/2. Because the function performs no validation on the input string, any \r\n characters survive into Tesla.Multipart.headers/1, where they are emitted verbatim. The resulting raw bytes terminate the legitimate Content-Type header and start a new header line, giving attackers control over the outbound request structure. The downstream impact depends on the target server, but typical consequences include header overwrite, request smuggling against shared proxies, and unintended routing or authentication behavior.

Root Cause

The root cause is improper neutralization of CRLF sequences in HTTP headers (CWE-113). Tesla.Multipart.add_content_type_param/2 accepts a string and appends it to an internal list without filtering or rejecting CR and LF bytes. Tesla.Multipart.headers/1 then joins those entries with "; " and emits the result directly as the Content-Type header value, with no escaping or validation pass before serialization.

Attack Vector

Exploitation requires an application that forwards untrusted input into add_content_type_param/2. A common case is an API endpoint that accepts a charset, boundary, or other parameter from a client and passes it to the Tesla multipart builder. The attacker supplies a payload containing \r\n followed by an attacker-chosen header line. Tesla emits the crafted bytes into the outbound request, and the receiving server parses the injected header as legitimate. Refer to the GitHub Security Advisory GHSA-q7jx-v53g-848w and the fix commit for the precise code path and patch details.

Detection Methods for CVE-2026-48596

Indicators of Compromise

• Outbound HTTP requests containing Content-Type header values with embedded %0D%0A, \r\n, or unexpected additional header lines.
• Application logs showing user-supplied charset, boundary, or parameter values containing CR or LF characters.
• Anomalous duplicate or attacker-controlled headers (for example, injected Host, Authorization, or X-Forwarded-For) on requests originating from Elixir services.

Detection Strategies

• Perform a dependency audit of Elixir projects for tesla versions in the 0.8.0 to 1.18.2 range using mix deps or SBOM tooling.
• Conduct static code review for any call site invoking Tesla.Multipart.add_content_type_param/2 with values derived from request parameters, headers, or external data sources.
• Inspect egress proxy or web application firewall logs for outbound requests whose Content-Type header contains line terminators or unexpected secondary headers.

Monitoring Recommendations

• Enable verbose HTTP client logging in staging environments to capture raw outbound headers for review.
• Alert on outbound requests where header values contain 0x0D or 0x0A bytes after the initial header name boundary.
• Track upgrades of the tesla dependency across CI pipelines to confirm remediation reaches all services.

How to Mitigate CVE-2026-48596

Immediate Actions Required

• Upgrade the tesla dependency to version 1.18.3 or later in mix.exs and redeploy all affected Elixir services.
• Audit every call to Tesla.Multipart.add_content_type_param/2 and remove or sanitize untrusted input before it reaches the function.
• Add input validation that rejects any string containing \r or \n before constructing multipart requests.

Patch Information

The maintainers released the fix in tesla version 1.18.3. The corrective change is documented in the official fix commit and the GHSA-q7jx-v53g-848w advisory. Additional records are available at the CNA advisory and OSV entry.

Workarounds

• Where immediate upgrade is not possible, wrap calls to add_content_type_param/2 with a helper that rejects strings containing CR or LF bytes.
• Constrain user-supplied charset and parameter inputs to a strict allowlist of ASCII tokens before they reach Tesla.
• Place an egress proxy in front of Elixir services that normalizes or rejects HTTP requests containing malformed header values.

# Configuration example - update tesla in mix.exs
# {:tesla, "~> 1.18.3"}
mix deps.update tesla
mix deps.get
mix compile