CVE-2026-7017

What it actually does

HTTP::Tiny versions before 0.095 can leak caller-supplied credential-bearing HTTP headers during redirect handling. If a request includes explicit headers such as Authorization, Cookie, or Proxy-Authorization and the server responds with a 3xx Location pointing to a different scheme, host, or port, HTTP::Tiny follows the redirect and re-applies those headers to the redirected request without enforcing same-origin checks. This can disclose credentials to an attacker-controlled endpoint and can also downgrade HTTPS-originated credentials to plaintext HTTP if the redirect target uses http://.

Why it matters to the business

Applications, scripts, automation jobs, and package-management or integration tooling that use vulnerable HTTP::Tiny versions may unintentionally send API tokens, session cookies, proxy credentials, or bearer tokens to unauthorized servers. The likely business consequences are account takeover, unauthorized access to third-party services, exposure of internal service credentials, and follow-on data access using leaked secrets. The CVSS score is high, but the current EPSS is low and there is no known KEV listing, so organizations should prioritize remediation based on where HTTP::Tiny is used with sensitive headers and untrusted or externally controlled URLs.

How an attack unfolds

An attacker needs to influence the URL requested by software using HTTP::Tiny or control a server that the software legitimately contacts. The attacker returns an HTTP 3xx redirect with a Location header pointing to infrastructure they control, potentially changing the hostname, port, or scheme, including redirecting from HTTPS to HTTP. Vulnerable HTTP::Tiny versions then construct the redirected request and merge the original caller-provided headers into it. As a result, secrets such as Authorization, Cookie, or Proxy-Authorization are sent to the redirect target. The attacker captures those headers from web server logs, packet captures, or application handlers and reuses the exposed credentials against the original service or other services where the same secret is accepted.

How to fix it

Upgrade HTTP::Tiny to version 0.095 or later wherever it is bundled or installed. If immediate upgrade is not possible, disable automatic redirect following for requests that include sensitive headers, manually validate every redirect target before following it, and strip Authorization, Cookie, Proxy-Authorization, and other secret-bearing headers unless the redirect destination is the same origin as the original request. Block HTTPS-to-HTTP redirects for authenticated requests. Review Perl application dependencies, vendored modules, container images, base images, and system Perl packages because HTTP::Tiny is commonly present as a dependency or core-adjacent utility in automation environments. Rotate any credentials that may have been sent through vulnerable redirect flows, especially tokens used in automated integrations.

How to confirm the fix worked

Confirm that all deployed HTTP::Tiny copies report version 0.095 or later, including system packages, CPAN-installed modules, vendored libraries, and container images. Test behavior with a controlled redirect: send a request containing a harmless test Authorization header to an HTTPS endpoint that returns a 302 Location pointing to a different host, port, or http:// URL, then verify the redirected request does not contain the original sensitive headers. Review dependency manifests, SBOMs, package manager output, and runtime module paths to ensure older copies are not shadowing the upgraded module. Where applications implement their own redirect handling around HTTP::Tiny, validate that same-origin checks and header stripping are applied consistently.

Typical attack path

1. Identify an application, script, or automation workflow that uses HTTP::Tiny before version 0.095 and sends explicit credential headers.
2. Cause the application to request an attacker-controlled URL, or compromise/control a legitimate endpoint the application already calls.
3. Return a 3xx redirect response with a Location header pointing to an attacker-controlled cross-origin destination.
4. Optionally use an http:// redirect target to expose headers in plaintext on the network path.
5. Receive the redirected request containing Authorization, Cookie, Proxy-Authorization, or similar sensitive headers.
6. Extract the leaked credentials from server access logs, application logs, or packet capture.
7. Use the exposed credentials to access protected APIs, services, accounts, or proxy infrastructure.

How to detect it

To determine whether exploitation already occurred, examine application logs, outbound proxy logs, web gateway logs, DNS logs, EDR network telemetry, and packet captures for authenticated requests followed by cross-origin redirects. Focus on flows where an initial request received a 301, 302, 303, 307, or 308 response and the next request went to a different scheme, hostname, or port while still carrying Authorization, Cookie, Proxy-Authorization, or other secret-bearing headers. Pay special attention to HTTPS-to-HTTP downgrades and redirects to newly registered, unusual, external, or attacker-controlled domains. If HTTP::Tiny debugging or application request logging is enabled, search for redirect handling around '_maybe_redirect' behavior or repeated header sets across different origins. Also inspect server-side logs for destinations that received unexpected credential headers from automation user agents. Any confirmed credential forwarding to an untrusted origin should be treated as credential compromise and trigger token rotation and access review.

• HTTP::Tiny
• HTTP::Tiny/
• Authorization:
• Proxy-Authorization:
• Cookie:
• Location: http://
• 301 Moved Permanently
• 302 Found
• 303 See Other
• 307 Temporary Redirect
• 308 Permanent Redirect
• _maybe_redirect
• _prepare_headers_and_cb

What your security team should do

• Inventory Perl applications, scripts, CI/CD jobs, monitoring integrations, and automation tooling that use HTTP::Tiny before 0.095.
• Prioritize upgrade for workloads that send Authorization, Cookie, Proxy-Authorization, API keys, bearer tokens, or session credentials in explicit HTTP headers.
• Patch or rebuild containers, base images, and packaged appliances that include vulnerable HTTP::Tiny copies.
• Add tests that verify credential headers are not forwarded across scheme, host, or port changes during redirects.
• Block or alert on authenticated HTTPS requests that receive redirects to different origins or plaintext HTTP destinations.
• Review outbound proxy and egress logs for cross-origin redirects followed by requests carrying credential headers.
• Rotate credentials used by affected workflows if logs show suspicious redirects or if exposure cannot be ruled out.
• For high-sensitivity integrations, restrict allowed redirect destinations or disable redirects entirely when credentials are present.