A flaw was found in libcurl from versions 7.29.0 through 7.71.1. An application that performs multiple requests with libcurl"s multi API, and sets the `CURLOPT_CONNECT_ONLY` option, might experience libcurl using the wrong connection. The highest threat from this vulnerability is to data confidentiality. A malicious server can use the `PASV` response to trick curl into connecting back to a given IP address and port, and this way potentially make curl extract information about services that are otherwise private and not disclosed, for example doing port scanning and service banner extractions. If curl operates on a URL provided by a user, a user can exploit that and pass in a URL to a malicious FTP server instance without needing any server breach to perform the attack. Libcurl offers a wildcard matching functionality, which allows a callback to return information back to libcurl on how to handle a specific entry in a directory when libcurl iterates over a list of all available entries. When this callback returns `CURL_CHUNK_BGN_FUNC_SKIP`, to tell libcurl to not deal with that file, the internal function in libcurl then calls itself recursively to handle the next directory entry. If there"s a sufficient amount of file entries and if the callback returns "skip" enough number of times, libcurl runs out of stack space. The exact amount will of course vary with platforms, compilers and other environmental factors. Libcurl offers "OCSP stapling" via the CURLOPT_SSL_VERIFYSTATUS option. When set, libcurl verifies the OCSP response that a server responds with as part of the TLS handshake. It then aborts the TLS negotiation if something is wrong with the response. The same feature can be enabled with --cert-status using the curl tool. As part of the OCSP response verification, a client should verify that the response is indeed set out for the correct certificate. This step was not performed by libcurl when built or told to use OpenSSL as TLS backend