What happened
CVE-2026-48595 is a credential-disclosure vulnerability in Tesla, a popular HTTP client library for Elixir. The issue affects Tesla versions from 1.4.0 up to, but not including, 1.18.3 when an application uses Tesla.Middleware.FollowRedirects.
The middleware is designed to remove sensitive headers when a request follows a redirect to a different origin. The vulnerable implementation compares header names against a lowercase filter list using case-sensitive string matching. HTTP header names, however, are case-insensitive.
As a result, a header written using conventional casing such as Authorization does not match the lowercase filter entry authorization. When a cross-origin redirect occurs, the sensitive header can remain attached to the redirected request and be sent to the new destination.
The Erlang Ecosystem Foundation CNA rates the vulnerability High at CVSS 4.0 score 8.2. NVD also provides a CVSS 3.1 assessment of 5.9, illustrating how scores can differ between metric versions and evaluators. The affected library was fixed in Tesla 1.18.3.
How redirect credential leakage happens
HTTP clients often follow redirects automatically. A server can respond with a Location header pointing the client to another URL, and the client may issue a second request to that destination without requiring application code to construct it manually.
Forwarding an Authorization header to the same trusted origin may be expected. Forwarding it to a different host can expose bearer tokens, API credentials, or other secrets to a third party. Redirect middleware therefore needs to strip sensitive headers when the origin changes.
The vulnerable flow is:
Application sends authenticated request
|
v
Authorization header is present
|
v
Server returns cross-origin redirect
|
v
Tesla tries to remove sensitive headers
|
v
Case-sensitive comparison misses "Authorization"
|
v
Redirected request keeps the credential
|
v
New origin receives the secretThe flaw is classified as improper handling of case sensitivity. The security check assumes header names have already been normalized to lowercase, but Tesla preserves the header casing supplied by the caller.
What an attacker needs
The vulnerability is not triggered by every redirect. An attacker needs the Tesla application to follow a cross-origin redirect that the attacker can control or influence. The vendor advisory gives examples including an attacker-controlled endpoint, an upstream open redirect, or a compromised origin.
This requirement is reflected in the CVSS 4.0 assessment, which includes an attack requirement. The attacker does not necessarily need credentials or user interaction, but they need a way to cause the authenticated client to receive a redirect to a destination that can capture the forwarded header.
That means the real-world risk depends on what URLs the application requests, which upstream services can redirect those requests, and what credentials the Tesla client attaches. Internal API clients using long-lived bearer tokens can have a very different impact profile from a client making anonymous public requests.
Affected versions and fix
The affected package range is:
Tesla 1.4.0 through 1.18.2: AFFECTED when FollowRedirects is used
Tesla 1.18.3 and later: PATCHEDThe vendor's changelog for Tesla 1.18.3 lists CVE-2026-48595 among several security fixes. Applications should update the dependency and regenerate lockfiles or rebuild releases so the corrected library is actually deployed.
The vulnerability only applies when Tesla.Middleware.FollowRedirects is included in the middleware pipeline. Applications that do not use that middleware are not exposed through this specific code path.
The advisory also provides a temporary workaround: normalize header keys to lowercase before passing them to Tesla and use authorization rather than Authorization when setting the header. Updating to the patched release remains the preferred remediation.
Why it matters for website owners
Website back ends frequently make outbound HTTP requests to payment services, identity providers, analytics APIs, storage systems, CRMs, internal microservices, and other application dependencies. Those requests often include credentials that are not visible from the public website but are valuable to attackers.
A redirect credential leak can therefore turn an upstream URL-handling weakness into secret disclosure. If the exposed value is a bearer token, possession of the token may be sufficient to call the external API until the credential expires or is revoked.
The website itself does not have to redirect a browser for this vulnerability to matter. The affected redirect occurs inside the server-side Elixir application. A user may see no visible sign that the HTTP client followed another origin.
Organizations should treat outbound HTTP behavior as part of application security. Redirect policies, credential scoping, token lifetime, and destination allowlists can all influence the impact of a client-library flaw.
What to check on your site
- Inventory Tesla versions. Check Mix dependencies and deployed releases for Tesla versions from 1.4.0 through 1.18.2.
- Confirm middleware usage. Search application configuration for
Tesla.Middleware.FollowRedirects. - Review sensitive headers. Identify clients that send Authorization or other credential-bearing headers through Tesla.
- Inspect header casing. Determine whether credentials are set using canonical mixed-case names that could bypass the vulnerable lowercase filter.
- Review redirect destinations. Identify upstream services capable of redirecting authenticated requests to another origin.
- Audit open redirects. Upstream open redirect weaknesses can become a prerequisite that makes the Tesla bug exploitable.
- Review credential logs. If suspicious redirects occurred, check whether tokens were used from unexpected addresses or against unexpected services.
- Rotate exposed secrets. Any bearer token or credential confirmed to have reached an untrusted origin should be revoked and replaced.
Recommended response
Update Tesla to version 1.18.3 or later, rebuild the application, and verify that production is using the corrected dependency. Teams using dependency caching or long-lived releases should not assume that changing mix.exs alone updates the running artifact.
If immediate patching is impossible, normalize outgoing header keys to lowercase before Tesla processes them and avoid using the vulnerable mixed-case Authorization header with the FollowRedirects middleware. Consider disabling automatic cross-origin redirects for high-value authenticated clients where application behavior permits it.
Review the destinations that authenticated HTTP clients are allowed to reach. An allowlist for critical integrations can reduce the chance that a manipulated Location header sends a credential to an arbitrary domain.
If a leak is suspected, rotate the affected token even if no malicious use has yet been observed. Bearer credentials are valuable precisely because an attacker can often use them without additional proof of identity.
Redirect security beyond this CVE
CVE-2026-48595 demonstrates how redirect security affects more than browser phishing. Server-side HTTP clients can follow redirects while carrying authorization state, cookies, custom API keys, or internal metadata.
Developers should define whether redirects are required, whether protocol downgrades are allowed, how many hops are acceptable, and which headers survive an origin change. Sensitive headers should generally be removed whenever the scheme, host, or port moves outside the trusted authentication boundary.
Upstream services should also avoid open redirects. An open redirect that seems low impact in a browser context can become a credential exfiltration primitive when a trusted backend client follows it automatically.
Using Vulnify for follow-up review
Vulnify's Redirect Chain Checker can help inspect the public redirect path of a URL and identify unexpected cross-domain hops. The Open Redirect Checker can help assess whether a public endpoint appears to redirect visitors to attacker-controlled destinations.
These tools are relevant for mapping public redirect behavior, but they cannot inspect an internal Elixir process or prove that Tesla forwarded an Authorization header. Dependency and code-level review are still required for CVE-2026-48595.
Developers can also use the Headers Analyzer to review HTTP response headers exposed by web endpoints. Response header hardening is separate from the client-library bug, but it can form part of a broader HTTP security review.
Operational prioritization
For larger Elixir estates, the first priority should be services that combine three conditions: a vulnerable Tesla version, the FollowRedirects middleware, and reusable Authorization credentials on outbound requests. Applications missing any one of those conditions have a different exposure profile for this specific CVE.
Dependency inventories and software bills of materials can help identify vulnerable Tesla versions, while code search can locate middleware configuration and calls that add authorization headers. Teams should then map the upstream destinations those clients contact and determine whether any of them can redirect to untrusted origins.
After the library is updated, rotate credentials only where exposure is plausible or confirmed rather than indiscriminately replacing every application secret. Focus on tokens that may have accompanied cross-origin redirects during the vulnerable period. Logs from outbound proxies, API gateways, and destination services can help establish whether sensitive requests followed unexpected Location headers.
Related reading
Conclusion
CVE-2026-48595 affects Tesla's redirect middleware because security-sensitive header filtering is case sensitive even though HTTP header names are not. A normally cased Authorization header can therefore survive a cross-origin redirect and be sent to an untrusted destination.
The issue affects Tesla 1.4.0 through 1.18.2 when Tesla.Middleware.FollowRedirects is used and is fixed in version 1.18.3. Exploitation also requires the attacker to control or influence a redirect seen by the client.
Elixir application owners should update the dependency, review authenticated clients that follow redirects, audit upstream open redirects, and rotate any credentials known to have reached an unintended origin. The wider lesson is that redirect handling must treat origin changes as a security boundary, especially when server-side clients carry reusable credentials.