Summary: Curl will reuse existing certificate for further TLS requests when following redirects. This is similar to CVE 2022-27774 but with narrower impact, as the secret (private key) is not leaked. Steps To Reproduce: Configure a site (targetsite.tld) to require client certificates for authentication Have client.crt and client.key that can be used to access this site Create an attacker controller site https://evilsite.tld/something that redirects to https://targetsite.tld/secretfile curl -L --cert client.crt --key client.key https://evilsite.tld/something The redirect is followed and the secretfile content fetched In effect the attacker can choose which content is accessed with the client certificate. This proof of concept is of course rather silly as one-liner curl command, but it still demonstrates the inability of libcurl to restrict where key/cert are used. This scenario of course requires that the application in question can be passed attacker controlled URLs and that redirects are followed. If the attacker also wishes to obtain the secretfile response the application in question should be returning the file contents to the request to the attacker (lets assume attacker can pass URLs the app and gets the fetched content back as result). Configuring client key/cert for arbitrary requests is unwise. However, since the common understanding is that the client certificate public key is "useless" to the attacker without the corresponding private key, it might happen that...