curl vulnerabilities

When curl is told to use the Certificate Status Request TLS extension (OCSP stapling) to verify the server certificate, it might fail to detect some OCSP problems and wrongly consider the response as fine. If the returned status reports an error other than 'revoked' (e.g. 'unauthorized'), it is not treated as a bad certificate.

When a protocol selection parameter option disables all protocols without adding any then the default set of protocols would remain in the allowed set due to an error in the logic for removing protocols. The flaw is only present if the set of selected protocols disables the entire set of available protocols, in itself a command with no practical use and therefore unlikely to be encountered in real situations. The curl security team has thus assessed this to be low severity bug.

In curl 7.65.2, an integer overflow occurs in tool_operate.c with a large retry delay value.

An information disclosure vulnerability in curl before v8.1.0 during HTTP(S) transfers. If the same handle was previously used for a PUT request with a read callback and then for a POST with CURLOPT_POSTFIELDS set, libcurl may erroneously invoke the read callback and send wrong data or use memory after free.

An improper certificate validation vulnerability in curl < v8.1.0 exists in the way it matches wildcard patterns in the Subject Alternative Name of TLS server certificates. curl's private wildcard matching function incorrectly matches IDN hostnames, potentially accepting patterns that should mismatch.

A denial of service vulnerability in curl < v8.1.0 exists in the way libcurl provides different backends for resolving host names. With the synchronous resolver, name resolves can time-out slow operations using alarm() and siglongjmp(), and libcurl used a global buffer not protected by a mutex, so a multi-threaded application might crash or misbehave.

A use-after-free vulnerability exists in curl < v8.1.0 in libcurl's feature to verify an SSH server's public key using a SHA 256 hash. When this check fails, libcurl frees the memory for the fingerprint before returning an error message containing the (now freed) hash, risking insertion of sensitive heap-based data into the error message.

A path traversal vulnerability exists in curl <8.0.0 SFTP implementation causes the tilde (~) character to be wrongly replaced when used as a prefix in the first path element, in addition to its intended use as the first element to indicate a path relative to the user's home directory. Attackers can exploit this flaw to bypass filtering or execute arbitrary code by crafting a path like /~2/foo while accessing a server with a specific user.

A vulnerability in curl before 7.88.0 involves unlimited decompression steps in chained HTTP compression algorithms. The limit was applied per-header, allowing a malicious server to insert virtually unlimited compression steps, resulting in a malloc bomb and excessive heap memory allocation.

A cleartext transmission of sensitive information vulnerability exists in curl <v7.88.0 that could cause HSTS functionality to behave incorrectly when multiple URLs are requested in parallel. The HSTS cache file gets overwritten by the most recently completed transfer, so a later HTTP-only transfer to the earlier host name would not get upgraded properly to HSTS.

A use after free vulnerability exists in curl <7.87.0. Curl can be asked to *tunnel* virtually all protocols it supports through an HTTP proxy. HTTP proxies can (and often do) deny such tunnel operations. When getting denied to tunnel the specific protocols SMB or TELNET, curl would use a heap-allocated struct after it had been freed, in its transfer shutdown code path.

curl can be told to parse a `.netrc` file for credentials. If that file ends in a line with 4095 consecutive non-white space letters and no newline, curl would first read past the end of the stack-based buffer, and if the read works, write a zero byte beyond its boundary. This will in most cases cause a segfault or similar, but circumstances might also cause different outcomes. If a malicious user can provide a custom netrc file to an application or otherwise affect its contents, this flaw could be used as denial-of-service.

Double free vulnerability in curl before 7.86.0 (earliest affected version is 7.77.0). It occurs when curl is told to use an HTTP proxy for a transfer with a non-HTTP(S) URL scheme (dict, gopher, gophers, ldap, ldaps, rtmp, rtmps, or telnet) and the proxy refuses the CONNECT request by returning a non-200 status code.

When curl is used to retrieve and parse cookies from a HTTP(S) server, it accepts cookies using control codes that when later are sent back to a HTTP server might make the server return 400 responses. Effectively allowing a "sister site" to deny service to all siblings.

curl's HSTS support can be bypassed when the host name in the URL uses a trailing dot while the HSTS cache entry does not (or vice versa). This allows the insecure clear-text HTTP step to occur despite HSTS being enabled.

The curl URL parser wrongly accepts percent-encoded URL separators like '/' when decoding the host name part of a URL, making it a *different* URL using the wrong host name when it is later retrieved. For example, a URL like `http://example.com%2F127.0.0.1/` would be allowed by the parser and get transposed into `http://example.com/127.0.0.1/`. This flaw can be used to circumvent filters, checks and more.

A use of incorrectly resolved name vulnerability fixed in 7.83.1 might remove the wrong file when `--no-clobber` is used together with `--remove-on-error`.

An information disclosure vulnerability exists in curl versions 7.65.0 to 7.82.0 that allows reusing a connection using an IPv6 address with a different zone id.

A vulnerability in curl from version 4.9 up to and including 7.82.0 related to insufficient protection of credentials. When following HTTP(S) redirects with authentication, credentials may leak to other services on different protocols or ports.

An improper authentication vulnerability exists in curl versions 7.33.0 to 7.82.0 which might allow reuse of OAUTH2-authenticated connections without properly ensuring that the connection was authenticated with the same credentials. This affects SASL-enabled protocols: SMPTP(S), IMAP(S), POP3(S), and LDAP(S) (openldap only).

When curl >= 7.20.0 and <= 7.78.0 connects to an IMAP or POP3 server to retrieve data using STARTTLS to upgrade to TLS security, the server can respond and send back multiple responses at once that curl caches. Curl would then upgrade to TLS but not flush the in-queue of cached responses, instead continuing to use and trust responses received before the TLS handshake as if they were authenticated. This flaw allows a Man-In-The-Middle attacker to inject fake responses, pass through TLS traffic from the legitimate server, and trick curl into sending data back to the user thinking the injected data comes from the TLS-protected server.

When curl is instructed to get content using the metalink feature, and a user name and password are used to download the metalink XML file, those same credentials are then subsequently passed on to each of the servers from which curl will download or try to download the contents from. Often contrary to the user's expectations and intentions and without telling the user it happened.

curl 7.61.0 through 7.76.1 suffers from exposure of data element to wrong session due to a mistake in the code for CURLOPT_SSL_CIPHER_LIST when libcurl is built to use the Schannel TLS library. The selected cipher set was stored in a single "static" variable in the library, which has the surprising side-effect that if an application sets up multiple concurrent transfers, the last one that sets the ciphers will accidentally control the set used by all transfers. In a worst-case scenario, this weakens transport security significantly.

curl 7.63.0 through 7.75.0 allows a malicious HTTPS proxy to MITM a connection due to bad handling of TLS 1.3 session tickets. libcurl can confuse session tickets from the HTTPS proxy with those from the remote server and use the wrong ticket for session resumption.

A non-privileged user or program can put code and a config file in a known non-privileged path (under C:/usr/local/) that will make curl <= 7.65.1 automatically run the code (as an openssl "engine") on invocation. If that curl is invoked by a privileged user it can do anything it wants.