CVE-2026-48595: Authorization header leaks to third-party origin on cross-origin redirect in Tesla.Middleware.FollowRedirects

Synopsis

An improper case-sensitivity handling flaw in the Tesla HTTP client library for Elixir (elixir-tesla/tesla) causes the FollowRedirects middleware to forward Authorization headers to third-party origins on cross-origin redirects. The vulnerability is reachable over the network without any authentication, because an attacker only needs to influence a redirect Location response seen by the Tesla client (for example, by controlling a redirect endpoint or exploiting an open redirect on a trusted origin). Successful exploitation leaks bearer tokens or other Authorization credentials to an attacker-controlled server. A patched-image rebuild at version 1.18.3 is available on HarborGuard for environments running an affected version.

HarborGuard Coverage

Exploit Conditions

• Network reachabilityRequired

  The attacker must be reachable over the network as a redirect destination, or must be able to influence a Location header returned to the Tesla client from a network-accessible endpoint.

• AuthenticationNot required

  No account or credential is required to exploit this; the attacker simply needs to receive the redirected HTTP request.

• Victim interactionNot required

  No user action is needed; the Tesla client follows the redirect automatically without any human interaction.

• Attack complexityDetail

  The exploit is generally reliable and condition-free, though the CVSS vector notes an attack requirement of a specific prerequisite condition (AT:P), meaning the attacker must be positioned to control or influence a redirect response seen by the client, such as by operating a redirect endpoint or exploiting an open redirect on a trusted origin.

Blast Radius

• The attacker receives the raw Authorization header value, typically a bearer token or Basic credentials, sent by the Tesla client to the legitimate origin.
• With a stolen bearer token, the attacker can authenticate to the protected API as the original client and read any data that token authorizes, such as stored user records, session data, or API responses.
• Credential leakage is silent from the legitimate service's perspective because the token is valid; there is no error condition that would alert the victim application.