CVE-2026-48595: Tesla Credential Leakage Vulnerability

CVE-2026-48595 Overview

CVE-2026-48595 affects the elixir-tesla HTTP client library for Elixir. The Tesla.Middleware.FollowRedirects module fails to strip security-sensitive headers on cross-origin redirects because it uses a case-sensitive comparison against a lowercase filter list. HTTP header names are case-insensitive per RFC 7230, but Tesla preserves caller-supplied casing without normalization. A header set as {"Authorization", "Bearer ..."} bypasses the filter and is forwarded to the redirect destination. The flaw is classified as [CWE-178] Improper Handling of Case Sensitivity and impacts tesla versions from 1.4.0 before 1.18.3.

Critical Impact
Attackers who control or influence a Location: response can harvest bearer tokens and other Authorization material from clients using vulnerable Tesla versions.

Affected Products

elixir-tesla/tesla versions 1.4.0 through 1.18.2
Elixir applications using Tesla.Middleware.FollowRedirects with non-lowercase header keys
Downstream services and SDKs built on vulnerable Tesla releases

Discovery Timeline

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

Technical Details for CVE-2026-48595

Vulnerability Analysis

The vulnerability resides in lib/tesla/middleware/follow_redirects.ex. When Tesla follows a redirect that changes origin, the middleware is expected to drop credentials before issuing the next request. The filter list is defined as @filter_headers ["authorization", "host"] and matches incoming header keys with a case-sensitive string comparison. Most HTTP libraries and documentation use the RFC 7235 canonical casing Authorization, which never matches authorization in this filter. As a result, the bearer token or other authentication material is replayed verbatim to the redirect target.

Exploitation requires an attacker-controlled redirect target or an upstream that can be coerced into emitting a Location: header pointing to attacker infrastructure. Common scenarios include open-redirect endpoints on trusted hosts, compromised SaaS origins, and SSRF chains that funnel outbound calls through an attacker-controlled service.

Root Cause

The root cause is the mismatch between HTTP semantics and the filter implementation. RFC 7230 defines header field names as case-insensitive, yet Tesla compares them as raw Elixir strings. Headers must be normalized to a canonical case before equality checks against a denylist.

Attack Vector

The attack is remote and unauthenticated against the Tesla client. The attacker needs only to influence the redirect destination observed by the client. Once the client follows the redirect, the Authorization header is transmitted to the attacker-controlled origin, exposing bearer tokens, API keys, and session credentials.

text

            env = %{env | opts: res.opts}

            env
-            |> filter_headers(prev_uri, next_uri)
+            |> filter_headers(prev_uri, next_uri, status)
            |> new_request(status, URI.to_string(next_uri))
            |> redirect(next, left - 1)
        end

Source: GitHub Commit db963dba. The patch reworks the filter_headers call signature alongside changes that perform case-insensitive header matching before forwarding requests across origins.

Detection Methods for CVE-2026-48595

Indicators of Compromise

Outbound HTTP requests from Elixir services to unexpected third-party origins immediately following a redirect response.
Web server access logs on attacker-controlled hosts containing Authorization: Bearer headers received from unrelated client IPs.
Application logs showing Tesla.Middleware.FollowRedirects traversing cross-origin Location: values to untrusted domains.
Bearer tokens or API keys appearing in third-party telemetry, error reports, or proxy logs where they should never be present.

Detection Strategies

Inventory all Elixir applications and their mix.lock files to identify tesla dependencies below version 1.18.3.
Search source code for use of Tesla.Middleware.FollowRedirects together with explicit Authorization headers set in callers.
Inspect egress proxy or WAF logs for requests where the Host header changes between consecutive hops while Authorization remains constant.
Correlate redirect response codes (301, 302, 303, 307, 308) to subsequent outbound requests crossing origin boundaries.

Monitoring Recommendations

Enable verbose Tesla middleware logging in non-production environments to confirm header stripping after upgrade.
Forward HTTP client telemetry to a centralized SIEM and alert on Authorization headers transmitted to domains outside an allowlist.
Rotate any bearer tokens or OAuth credentials that may have transited vulnerable clients during the exposure window.

How to Mitigate CVE-2026-48595

Immediate Actions Required

Upgrade tesla to version 1.18.3 or later in every Elixir project, then rebuild and redeploy affected services.
Audit code paths that attach Authorization headers and confirm the upgrade resolves the cross-origin leak.
Rotate bearer tokens, OAuth refresh tokens, and API keys that may have been exposed through prior redirects to untrusted hosts.
Restrict redirect-following to an allowlist of trusted destinations where business logic permits.

Patch Information

The fix is committed in elixir-tesla commit db963dba and shipped in tesla1.18.3. Details are available in the GitHub Security Advisory GHSA-9m9w-gxf7-rh8m, the Erlang Ecosystem Foundation CNA advisory, and the OSV vulnerability report.

Workarounds

Disable Tesla.Middleware.FollowRedirects and handle redirects manually with explicit header stripping when crossing origins.
Normalize all caller-supplied headers to lowercase before passing them into Tesla requests so the existing filter matches correctly.
Place an egress proxy in front of Elixir services that strips Authorization headers on any cross-origin redirect.

bash

# mix.exs - pin tesla to a patched release
{:tesla, "~> 1.18.3"}

# Then refresh and verify the locked version
mix deps.update tesla
mix deps.get
grep '"tesla"' mix.lock