CVE-2026-54171

What it actually does

Excon versions prior to 1.5.0 can forward sensitive HTTP headers while following redirects through the RedirectFollower middleware. When an application sends a request containing credentials or other confidential headers and the response redirects to a different target, Excon may include headers that should have been stripped from the follow-up request. This can disclose bearer tokens, API keys, session cookies, internal authentication headers, or other custom secrets to an unintended host. The flaw is confidentiality-only: it does not directly allow code execution, privilege escalation, or service disruption.

Why it matters to the business

Applications that use Excon to call external or semi-trusted URLs may leak authentication material to third parties if redirects are followed. Exposed tokens or cookies could allow unauthorized access to downstream APIs, customer data, cloud services, or internal services depending on what headers the application sends. The issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score, but the operational impact can still be significant where high-privilege API credentials are transmitted in HTTP headers.

How an attack unfolds

An attacker needs to influence an Excon-based application into making an HTTP request to a URL that will redirect, or compromise/control a service that the application already calls. The initial request contains sensitive headers such as Authorization, Cookie, X-Api-Key, or application-specific secrets. The attacker-controlled endpoint returns an HTTP 3xx response with a Location header pointing to another attacker-controlled host or path. Vulnerable Excon RedirectFollower logic follows the redirect and carries additional sensitive headers into the redirected request instead of stripping them. The attacker then reads the received headers from their web server logs or request capture tooling and can reuse any valid leaked credentials against the relevant service until they expire or are revoked.

How to fix it

Upgrade Excon to version 1.5.0 or later. If Excon is present as a transitive dependency, update the parent gem and regenerate the lockfile so the resolved Excon version is no longer vulnerable. For Bundler-managed applications, run a targeted update such as `bundle update excon` and confirm Gemfile.lock resolves Excon to 1.5.0 or newer. Where immediate upgrade is not possible, disable automatic redirect following for requests that include sensitive headers, avoid sending credentials to URLs that can redirect across origins, enforce an allowlist of redirect destinations, and explicitly strip Authorization, Cookie, API key, and custom secret-bearing headers before following redirects. Rotate any credentials that may have been sent through redirect flows while vulnerable.

How to confirm the fix worked

Confirm the deployed application resolves Excon to version 1.5.0 or later using Gemfile.lock, `bundle info excon`, `bundle list`, or software composition analysis output. Add or run an integration test where Excon sends a request with sensitive headers to a URL that redirects to a different host and verify the redirected request does not contain those headers. Review application configuration to determine where RedirectFollower is enabled and confirm sensitive requests either use the patched version, do not follow redirects, or strip headers on redirects. Validate production artifacts, containers, and build images rather than only source repositories, because Ruby dependency versions can differ between development and runtime environments.

Typical attack path

1. Identify an application or integration that uses Ruby Excon with RedirectFollower enabled on a version prior to 1.5.0.
2. Find a request path where the application sends sensitive headers and follows HTTP redirects.
3. Cause the application to request an attacker-controlled URL, or wait for it to call a service the attacker controls or can redirect.
4. Return an HTTP 301, 302, 303, 307, or 308 response with a Location header pointing to an attacker-controlled destination.
5. Capture the redirected request and extract leaked headers such as authorization tokens, cookies, or API keys.
6. Attempt to reuse the exposed credentials against their intended services before expiration or revocation.

How to detect it

To determine whether exploitation or accidental exposure occurred, review outbound HTTP telemetry for redirect chains where the original destination and final destination differ by host, domain, scheme, or port and the request included sensitive headers. Useful sources include application HTTP client debug logs, centralized application logs, egress proxy logs, web gateway logs, service mesh telemetry, packet capture where legally and operationally appropriate, and logs from any controlled redirect endpoints or partner services. Search for 3xx responses followed immediately by requests from the same application instance to a different host containing Authorization, Cookie, X-Api-Key, X-Auth-Token, or organization-specific secret headers. Investigate unexpected outbound requests to unfamiliar domains following redirects, especially if the request path, trace ID, or user agent indicates Ruby Excon. If leaked credentials are suspected, correlate the exposure time with downstream authentication logs for unusual use of the same token, API key, session cookie, or service account from new IP addresses, geographies, user agents, or services. Because this vulnerability produces credential leakage rather than a distinctive exploit payload, absence of known exploit strings does not prove absence of exposure.

What your security team should do

• Inventory Ruby applications and services that include the Excon gem, prioritizing internet-facing systems, API clients, webhook processors, cloud integrations, and services that call user-supplied or partner-controlled URLs.
• Upgrade Excon to 1.5.0 or later and redeploy affected applications; verify the fixed version in runtime artifacts and lockfiles.
• Identify redirect-following HTTP requests that include Authorization, Cookie, X-Api-Key, or custom secret headers, and restrict redirects to trusted destinations.
• Rotate credentials that may have been exposed through cross-origin redirect chains while vulnerable, prioritizing long-lived API keys and high-privilege service tokens.
• Review outbound HTTP logs, proxy logs, and partner/service logs for evidence that sensitive headers were sent to unexpected hosts after redirects.
• Add regression tests and secure HTTP client standards requiring header stripping on cross-origin redirects.