CVE-2026-7017: HTTP::Tiny Credential Header Leakage on Cross-Origin Redirects

Technical summary

The vulnerability exists in HTTP::Tiny's redirect handling logic. The `_maybe_redirect` function processes Location headers from 3xx responses, and `_prepare_headers_and_cb` re-merges caller-supplied headers without origin validation. Specifically: 1. Caller-supplied Authorization, Cookie, and Proxy-Authorization headers are preserved across redirects. 2. No check occurs to compare the redirect target's scheme, host, or port against the original request URL. 3. HTTPS-to-HTTP downgrades are permitted, exposing credentials in plaintext on the wire. 4. The library's existing documentation note about not including Authorization headers in redirects applied only to URL-embedded Basic auth (userinfo), not explicitly-passed header credentials. Versions before 0.095 are affected.

Business impact

Organizations using HTTP::Tiny in applications that handle sensitive APIs or authenticated services face credential compromise. If an application uses HTTP::Tiny to make requests with embedded credentials and is redirected to a malicious endpoint, those credentials—including session tokens, API keys in Authorization headers, or session cookies—may be captured by attackers. The impact is heightened if internal services or third-party integrations redirect traffic; a compromise could enable lateral movement, account takeover, or unauthorized API access. The severity increases if applications perform HTTPS-to-HTTP downgrades during redirects, exposing credentials in cleartext.

Affected systems

Any Perl application or service using HTTP::Tiny versions before 0.095 that: - Passes explicit Authorization, Cookie, or Proxy-Authorization headers to HTTP::Tiny requests. - Makes requests to URLs controlled by untrusted or potentially compromised servers. - Relies on HTTP::Tiny for authenticated API calls, service-to-service communication, or interactions with third-party endpoints. This includes web frameworks, API clients, monitoring tools, and microservices written in Perl that delegate HTTP operations to HTTP::Tiny.

Exploitability

Exploitation requires user interaction (reflected in the CVSS vector UI:R) and relies on an attacker controlling or compromising an HTTP endpoint to issue a malicious redirect. An attacker would: 1. Set up or compromise a server that the target application requests. 2. Configure it to return a 3xx redirect to an attacker-controlled host. 3. When HTTP::Tiny follows the redirect, credentials in the original request headers are forwarded to the attacker's host. No special privileges or complex attack chain is required beyond hosting a redirect endpoint. The risk is highest for applications that make requests to external or less-trusted services, or where an attacker can perform DNS hijacking or network interception. The attack surface is broad because HTTP::Tiny is commonly used and many developers may not expect credentials to leak across origin boundaries on redirect.

Remediation

Upgrade HTTP::Tiny to version 0.095 or later. This version implements origin validation for redirects and will not re-send caller-supplied credential headers to cross-origin redirect targets. For defense-in-depth, review all uses of HTTP::Tiny in your codebase: - Limit credential headers to trusted, first-party endpoints only. - Consider using per-request credential scoping rather than passing credentials globally. - For external API calls, use short-lived tokens or API keys with minimal scope. - Validate that redirect targets match expected domains before following them (if custom redirect logic is implemented).

Patch guidance

Patch by upgrading HTTP::Tiny to version 0.095 or later. Check your Perl package manager (CPAN, cpanminus, or system package manager) for availability. Verify the upgrade with `perl -MHTTP::Tiny -e 'print HTTP::Tiny->VERSION'` to confirm the new version is in use. Test your application's HTTP interactions after patching, particularly those involving redirects or credential-based authentication, to ensure no behavioral changes affect normal operation.

Detection guidance

Monitor for: 1. HTTP requests with Authorization, Cookie, or Proxy-Authorization headers that are followed by redirect responses and subsequent requests to different origins (hostname/port/scheme changes). 2. Logs from HTTP::Tiny or your application showing redirects to unexpected external hosts. 3. Network traffic patterns showing credentials being transmitted over unencrypted HTTP (HTTPS-to-HTTP downgrades). 4. Intrusion detection rules for cross-origin credential forwarding or unusual redirect behavior. Review application logs and packet captures for instances where credentials were sent to non-origin-matching redirect targets, and investigate whether any attacker-controlled redirects occurred.

Why prioritize this

This vulnerability scores 7.1 (HIGH) and combines credential exposure with a low barrier to exploitation. The CVSS vector reflects that: - Network attack surface (AV:N): HTTP::Tiny is used for remote service communication. - Low complexity (AC:L): Exploitation requires only a malicious redirect endpoint. - User interaction (UI:R): The application must initiate a request to a compromised/attacker-controlled server. - High confidentiality impact (C:H): Credentials are leaked. - Limited integrity impact (I:L): Attackers gain access to authenticated operations but do not directly modify the original service. Prioritize patching for applications handling sensitive credentials, integrating with external APIs, or deployed in threat environments where redirect hijacking is plausible.

Risk score, explained

CVSS 7.1 reflects a HIGH-severity credential exposure with practical exploitability. The score accounts for: - Direct confidentiality breach (leaked credentials). - Requirement for user/application interaction (must make a request that gets redirected). - Network-accessible attack vector (any HTTP endpoint can issue a redirect). - Low attack complexity (no special techniques needed). The score does not account for the likelihood that an application will be redirected to an attacker-controlled endpoint, which depends on threat model and operational context. In environments where external redirects are frequent or attacker-controlled, real-world risk is higher.

Frequently asked questions