Redirect credential leakage across scheme/port in HTTP.jl

Description

Redirect handling decided whether to retain credential-bearing headers (Authorization, Cookie, Proxy-Authorization, etc.) by comparing only the hostname, ignoring scheme and port. As a result an https→http downgrade or a same-host/different-port redirect was treated as same-origin and replayed credentials over plaintext or to a different service. Additionally, per-call cookies= cookies were captured once and re-appended on every hop even after the Cookie header was stripped, and the TLS verification host was pinned to the original host across redirects.

Impact

Following an attacker-influenced redirect could disclose a client's credentials or cookies to a different origin (different scheme or port) than the one they were intended for, including over plaintext.

Patches

Fixed in HTTP.jl v2.4.0. Sensitive-header retention now requires matching scheme and port (with default-port normalization) in addition to the existing host/subdomain check, cross-origin hops also clear the explicit cookies= vector so they are not re-attached, and the SNI/verification host is recomputed from the redirect target on every hop unless the caller explicitly pinned server_name.

Reported to the JuliaLang security team through Anthropic's Coordinated Vulnerability Disclosure program.