CVE-2026-48595: Cross-Origin Credential Leakage in Elixir Tesla Client via Case-Sensitive Redirect Filter Bypass

The Elixir HTTP client library Tesla provides an extensible system of pluggable middleware to intercept and modify outgoing requests and incoming responses. Among these, the 'Tesla.Middleware.FollowRedirects' middleware is widely deployed to automate the handling of HTTP redirect status codes. To ensure standard secure transport practices, this middleware is engineered to strip sensitive authorization materials and routing metadata when transitioning from an authorized source to an external, cross-origin host.

However, a design oversight in version 1.4.0 through 1.18.2 exposed users to credential exposure risks. The validation routine implemented to drop sensitive headers relied on strict case-sensitive comparisons against a hardcoded lowercase blocklist. Because Elixir preservation rules keep the casing of headers as defined by callers, common canonical headers bypassed this sanitation step completely.

This vulnerability is classified under CWE-178 (Improper Handling of Case Sensitivity). If an application communicates with services that support user-supplied URLs or suffer from open redirect flaws, an attacker can manipulate the destination target to capture the intact authentication headers.

To understand the core flaw, it is necessary to examine how Elixir's Tesla maps HTTP state. Inside the %Tesla.Env{} structure, HTTP headers are represented as an ordered list of two-element tuples, where each tuple contains a header key and its associated value. To guarantee compatibility with lower-level adapters, Tesla retains the precise capitalization provided during request initialization.

According to HTTP RFC 9110, header field names must be treated as case-insensitive. However, the pre-patch middleware implementation assessed filter eligibility using standard Elixir list membership semantics. Specifically, the line k not in @filter_headers executed a direct equality evaluation against the lowercase-only list ["authorization", "host"].

Because the string comparison did not normalize the character case of the runtime headers, any keys possessing capital letters failed the lookup block. The comparison "Authorization" not in ["authorization", "host"] returned true, meaning the header was kept instead of being filtered out. Consequently, the client library successfully transmitted the intact header to the subsequent redirect target.

The vulnerable version of the library defined a static module attribute @filter_headers and processed keys through a basic filter operation. The block below showcases the original, inadequate validation loop:

# PRE-PATCH VULNERABLE LOGIC
@filter_headers ["authorization", "host"]
 
defp filter_headers(env, prev, next) do
  if next.host != prev.host || next.port != prev.port || next.scheme != prev.scheme do
    %{env | headers: Enum.filter(env.headers, fn {k, _} -> k not in @filter_headers end)}
  else
    env
  end
end

The patched code introduces a robust, RFC-compliant architecture. By converting input keys to lowercase during evaluation, the application establishes case-insensitivity regardless of how callers capitalized the key names:

# PATCHED LOGIC - COMMIT db963dba67651b9abd1fc420a1d9679cf6efe182
@always_strip ~w(
  connection keep-alive proxy-connection te trailer transfer-encoding upgrade
  if-match if-modified-since if-none-match if-range if-unmodified-since
)
 
@cross_origin_strip ~w(
  authorization cookie host origin proxy-authorization referer
)
 
defp filter_headers(env, prev, next, status) do
  drop =
    @always_strip
    |> add_if(cross_origin?(prev, next), @cross_origin_strip)
    |> add_if(method_changes?(status), @method_change_strip)
 
  %{env | headers: Enum.reject(env.headers, &dropped?(&1, drop))}
end
 
defp dropped?({key, _value}, drop), do: String.downcase(key) in drop

The helper function dropped?/2 uses String.downcase(key) before executing the membership check. Furthermore, the expansion of the filter blocklist ensures conformity with RFC 9110 §15.4 directives, preventing secondary exposures of caching validators and hop-by-hop credentials.

Exploiting this vulnerability relies on an attacker's ability to trigger or manipulate a cross-origin redirect sequence. This pattern is common in applications processing webhooks, interacting with federated APIs, or handling user-influenced file URLs. The following diagram illustrates the sequence of the attack flow:

In a real-world vector, the Elixir client initiates an API request with canonical credentials, such as [{"Authorization", "Bearer token_xyz"}]. The target endpoint issues an HTTP 302 redirect pointing to http://attacker-controlled.com/. Because the domain differs, the middleware attempts to filter the headers but fails due to the uppercase 'A'.

The subsequent request to the attacker's server contains the original header, allowing the attacker to capture the credential. A proof-of-concept repository demonstrating this flow and detailing verification scaffolding is accessible at https://github.com/jenniferreire26/CVE-2026-48595.

The vulnerability carries a CVSS 4.0 base score of 8.2, reflecting high confidentiality impact. A successful exploitation allows external adversaries to intercept active session tokens, OAuth bearer strings, and cookie values.

With these credentials, the adversary can impersonate the affected service, elevate privileges, or compromise secondary APIs. The attack requires no prior authentication and can be completed entirely over the network.

While the probability of exploitation remains moderate depending on the design of internal API architectures, the risk is elevated for applications interacting with dynamic third-party resources. Given that most developer toolkits automatically generate capital-cased headers, the vast majority of deployments remain susceptible prior to applying updates.

Upgrading the tesla dependency to version 1.18.3 resolves this vulnerability permanently. This release incorporates the downcased header logic and expands the RFC blocklists to prevent credential leakages. Security teams should enforce this dependency constraint inside their Elixir projects.

If updating the library is temporarily blocked, developers can implement a custom pipeline plug to normalize all header keys to lowercase. By converting keys prior to hitting the FollowRedirects middleware, the case-sensitive filter routine evaluates the headers correctly:

defmodule MyApplication.HeaderSanitizer do
  def normalize_headers(env, next) do
    normalized = Enum.map(env.headers, fn {k, v} -> {String.downcase(k), v} end)
    %{env | headers: normalized} |> Tesla.run(next)
  end
end

Additionally, developers can manually define authorization parameters using strictly lowercase keys in their HTTP client calls. Doing so aligns the inputs with the legacy blocklist logic, enabling safe sanitization on redirection.