CVE-2026-6253: proxy credentials leak over redirect-to proxy

## Summary: When libcurl follows a redirect and the new URL causes proxy re-selection, proxy credentials learned from the originally selected proxy URL can remain in per-transfer state and be reused for the next proxy. In the validated case, a redirect from http:// to https:// switches selection from http_proxy to https_proxy, but credentials from http_proxy=http://user:pass@... are still sent to the https_proxy even when the https_proxy URL contains no credentials. A redirecting server can therefore cause libcurl to send Proxy-Authorization intended for proxy A to proxy B on proxy B’s first request. This appears limited to proxy credentials carried in transfer state, not the intentionally global CURLOPT_PROXYUSERNAME / CURLOPT_PROXYPASSWORD case. As a control, requesting the HTTPS URL directly with the same https_proxy does not send Proxy-Authorization to proxy B. I reproduced this on a local build and observed proxy B receive Proxy-Authorization: Basic dXNlcjpwYXNz on the initial CONNECT. ## Affected version Reproduced with: curl 8.20.0-DEV (Linux) libcurl/8.20.0-DEV OpenSSL/3.0.2 zlib/1.2.11 brotli/1.0.9 zstd/1.4.8 libidn2/2.3.2 libpsl/0.21.0 nghttp2/1.43.0 OpenLDAP/2.5.20 Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns ldap ldaps mqtt mqtts pop3 pop3s rtsp smtp smtps telnet tftp ws wss Features: alt-svc AsynchDNS brotli HSTS HTTP2 HTTPS-proxy IDN IPv6 Largefile libz PSL SSL threadsafe TLS-SRP UnixSockets zstd Git commit used: 935e1f9963a12ac1a880df538b23b824d2fea7bb Platform: Linux 6.8.0-1044-azure #50~22.04.1-Ubuntu SMP Wed Dec 3 15:13:22 UTC 2025 x86_64 GNU/Linux ## Steps To Reproduce: 1. Start an HTTP origin on 127.0.0.1:8000 that returns a redirect from /redir to https://127.0.0.1:8443/final. 2. Start an HTTPS origin on 127.0.0.1:8443 that serves /final. Any certificate is sufficient; curl -k is enough for local reproduction. 3. Start two HTTP-family proxies and log incoming request headers: - Proxy A on 127.0.0.1:8081 - Proxy B on 127.0.0.1:8082 4. Run: http_proxy=http://user:[email protected]:8081 \ https_proxy=http://127.0.0.1:8082 \ /path/to/curl -k -L http://127.0.0.1:8000/redir 5. Observe that the first HTTP request goes through proxy A and includes credentials for proxy A. 6. After the redirect to https://127.0.0.1:8443/final, libcurl re-selects proxy B via https_proxy. 7. Observe that proxy B receives a first request like: CONNECT 127.0.0.1:8443 HTTP/1.1 Host: 127.0.0.1:8443 Proxy-Authorization: Basic dXNlcjpwYXNz User-Agent: curl/8.20.0-DEV Proxy-Connection: Keep-Alive 8. As a control, if the same HTTPS URL is requested directly with only https_proxy=http://127.0.0.1:8082, proxy B does not receive Proxy-Authorization. ## Impact ## Summary: A redirecting server can cause libcurl to disclose credentials intended for one proxy to a different proxy under separate administrative control. This crosses a real proxy trust boundary and can expose reusable proxy secrets. Because proxy auth defaults to Basic, an HTTP-family second proxy can receive Proxy-Authorization on the very first request once stale proxy credentials survive the redirect. The issue is security-relevant even though it requires redirect following and a proxy-selection change, because the disclosure is demonstrable and occurs before any authentication challenge from the second proxy.