A vulnerability was found in curl. This security flaw allows reusing OAUTH2-authenticated connections without properly ensuring that the connection was authenticated with the same credentials set for this transfer. This issue leads to an authentication bypass, either by mistake or by a malicious actor. A vulnerability was found in curl. This security flaw allows leaking credentials to other servers when it follows redirects from auth-protected HTTP URLs to other protocols and port numbers. A vulnerability was found in curl. This security flaw occurs due to errors in the logic where the config matching function did not take the IPv6 address zone id into account. This issue can lead to curl reusing the wrong connection when one transfer uses a zone id, and the subsequent transfer uses another. A vulnerability was found in curl. This security flaw allows leak authentication or cookie header data on HTTP redirects to the same host but another port number. Sending the same set of headers to a server on a different port number is a problem for applications that pass on custom `Authorization:` or `Cookie:`headers. Those headers often contain privacy-sensitive information or data. A vulnerability was found in curl. The issue occurs because curl wrongly allows HTTP cookies to be set for Top Level Domains if the hostname is provided with a trailing dot. This flaw allows arbitrary sites to set cookies that get sent to a different and unrelated site or domain by a malicious actor. A vulnerability was found in curl. This issue occurs because the curl URL parser wrongly accepts percent-encoded URL separators like / when decoding the hostname part of a URL, making it a different URL using the wrong hostname when it is later retrieved. This flaw allows a malicious actor to make circumventing filters. A vulnerability was found in curl. This issue occurs because curl can reuse a previously created connection even when a TLS or SSH-related option is changed that should have prohibited reuse. This flaw leads to an authentication bypass, either by mistake or by a malicious actor. A vulnerability was found in curl. This issue occurs because when using its HTTP Strict Transport Security support, it can instruct curl to use HTTPS directly instead of using an insecure clear text HTTP step even when HTTP is provided in the URL. This flaw leads to a clear text transmission of sensitive information. A vulnerability was found in curl. This issue occurs because a malicious server can serve excessive amounts of `Set-Cookie:` headers in an HTTP response to curl, which stores all of them. This flaw leads to a denial of service, either by mistake or by a malicious actor. A vulnerability was found in curl. This issue occurs because the number of acceptable "links" in the "decompression chain" was unbounded, allowing a malicious server to insert a virtually unlimited number of compression steps. This flaw leads to a denial of service, either by mistake or by a malicious actor. A vulnerability was found in curl. This issue occurs because when curl saves cookies, alt-svc, and HSTS data to local files, it makes the operation atomic by finalizing the process with a rename from a temporary name to the final target file name. This flaw leads to unpreserved file permissions, either by mistake or by a malicious actor. A vulnerability was found in curl. This issue occurs because it mishandles message verification failures when curl does FTP transfers secured by krb5. This flaw makes it possible for a Man-in-the-middle attack to go unnoticed and allows data injection into the client. A vulnerability was found in curl. The issue occurs when doing HTTP transfers, where curl might erroneously use the read callback to ask for data to send, even when the option has been set if it previously used the same handle to issue a request which used that callback. This flaw may surprise the application and cause it to misbehave and either send off the wrong data or use memory after free or similar in the subsequent request. A vulnerability found in curl. This security flaw happens when curl is used to retrieve and parse cookies from an HTTP server, where it accepts cookies using control codes , and also when cookies that contain such control codes are later sent back to an HTTP server, possibly causing the server to return a 400 response. This issue effectively allows a "sister site" to deny service to siblings and cause a denial of service attack. A vulnerability was found in curl. The issue occurs when curl is told to parse a `.netrc` file for credentials. If that file ends in a line with consecutive non-white space letters and no newline, curl could read past the end of the stack-based buffer, and if the read works, it can write a zero byte beyond its boundary. This issue, in most cases, causes a segfault or similar problem. A denial of service can occur if a malicious user can provide a custom netrc file to an application or otherwise affect its contents. A vulnerability was found in curl. The issue occurs if curl is told to use an HTTP proxy for a transfer with a non-HTTP URL. It sets up the connection to the remote server by issuing a `CONNECT` request to the proxy and then tunnels the rest of the protocol through. An HTTP proxy might refuse this request and instead return a non-200 response code to the client. Due to flaws in the error/cleanup handling, this could trigger a double-free issue in curl if using one of the following schemes in the URL for the transfer: `dict,` `gopher,` `gophers,` `ldap`, `ldaps`, `rtmp`, `rtmps`, `telnet.` A vulnerability was found in curl. The issue occurs because curl's HSTS check can be bypassed to trick it to keep using HTTP. Using its HSTS support, it can instruct curl to use HTTPS directly instead of using an insecure clear-text HTTP step even when HTTP is provided in the URL. This mechanism can be bypassed if the hostname in the given URL uses IDN characters that get replaced with ASCII counterparts as part of the IDN conversion. Like using the character UTF-8 U+3002 instead of the common ASCII full stop . A vulnerability exists in curl less than 7.87.0 HSTS check that could be bypassed to trick it to keep using HTTP. Using its HSTS support, curl can be instructed to use HTTPS instead of using an insecure clear-text HTTP step even when HTTP is provided in the URL. However, the HSTS mechanism could be bypassed if the host name in the given URL first uses IDN characters that get replaced to ASCII counterparts as part of the IDN conversion. Like using the character UTF-8 U+3002 instead of the common ASCII full stop `.`. Then in a subsequent request, it does not detect the HSTS state and makes a clear text transfer. Because it would store the info IDN encoded but look for it IDN decoded. A vulnerability was found in curl. In this issue, curl can be asked to tunnel all protocols virtually it supports through an HTTP proxy. HTTP proxies can deny these tunnel operations using an appropriate HTTP error response code. When getting denied to tunnel the specific SMB or TELNET protocols, curl can use a heap-allocated struct after it has been freed and shut down the code path in its transfer