libcurl vulnerabilities

libcurl has an issue with reusing previously created connections even when TLS or SSH-related options have been changed that should prohibit reuse. Several TLS and SSH settings were left out from the configuration match checks, making them match too easily.

libcurl provides the `CURLOPT_CERTINFO` option to allow applications to request details about a server's certificate chain. Due to an erroneous function, a malicious server could make libcurl built with NSS get stuck in a never-ending busy-loop when trying to retrieve that information.

libcurl-using applications can request a specific client certificate to be used in a transfer. When built with the macOS native TLS library Secure Transport, a malicious user can trick the application into using a file-based certificate instead of the intended one, leading to the wrong client certificate being sent in the TLS handshake.

libcurl may read outside of a heap allocated buffer when doing FTP. A flaw in the string parser for the directory name may lead to a missing NUL byte at the end of the buffer, resulting in the potential to read data beyond the allocated memory area.

Use-after-free vulnerability in libcurl before version 7.50.1 allows attackers to control which connection is used or possibly have unspecified other impact via unknown vectors.

The ConnectionExists function in lib/url.c in libcurl before version 7.47.0 does not properly re-use NTLM-authenticated proxy connections, which might allow remote attackers to authenticate as other users via a request.

The curl_url_get() function in libcurl offers punycode conversions to and from IDN. When converting a name that is exactly 256 bytes, libcurl reads outside a stack-based buffer when built with the macidn IDN backend.

Due to a mistake in libcurl's WebSocket code, a malicious server can send a particularly crafted packet which makes libcurl get trapped in an endless busy-loop. There is no other way for the application to escape or exit this loop other than killing the thread/process. This might be used to DoS.

libcurl supports pinning of the server certificate public key for HTTPS transfers. Due to an omission, this check is not performed when connecting with QUIC for HTTP/3, when the TLS backend is wolfSSL. Documentation says the option works with wolfSSL, but fails to specify that it does not for QUIC.

libcurl's ASN1 parser has this utf8asn1str() function used for parsing an ASN.1 UTF-8 string. It can detect an invalid field and return error. Unfortunately, when doing so it also invokes `free()` on a 4 byte local stack buffer. Most modern malloc implementations detect this error and immediately abort.

libcurl accidentally skips certificate verification for QUIC connections when connecting to a host specified as an IP address in the URL. Therefore, it does not detect impostors or man-in-the-middle attacks.

A vulnerability in the libcurl library causes a memory leak when handling HTTP/2 server push. When an application allows server push and the number of headers exceeds the limit of 1000, libcurl aborts the push but fails to free previously allocated headers.

A flaw in libcurl causes it to wrongly reuse an HTTP connection established for a given hostname using Negotiate authentication, when the initial request is made with empty credentials. This can cause user B's request to be sent over user A's previously authenticated connection.

A flaw in libcurl's handling of HTTP/2 Server Push streams, when the parent handle is set to share connections with other handles, can lead to use-after-free in the cleanup process.

A flaw in libcurl caused the command to clear proxy authentication credentials to be ineffective, leaving old credentials in memory. These credentials were then used in subsequent transfers that should not have access to them.

A vulnerability in the libcurl library causes a leak of the proxy authorization header between requests. When reusing a libcurl handle for sequential transfers with environment-variable proxy configuration, the proxy authentication state is not cleared between requests. As a result, the `Proxy-Authorization:` header intended for one proxy may be sent to another.

A flaw in libcurl causes it to wrongly forward the Authorization header intended for one HTTP origin (hostA) to a different origin (hostB) when reusing the same handle after a Digest-authenticated transfer.

A vulnerability in the libcurl library involves the connection pool, which may retain connections using default native CA trust. When an application switches a handle to custom CA material, old connections might still be reused with the original trust settings.

A use-after-free vulnerability exists in libcurl when an application configures an HTTP/2 stream-dependency tree via CURLOPT_STREAM_DEPENDS or CURLOPT_STREAM_DEPENDS_E, subsequently invokes curl_easy_reset(), and finally terminates the handle with curl_easy_cleanup(). During this final cleanup phase, libcurl attempts to access and modify an internal structure that was already freed during the reset operation.

A vulnerability in libcurl related to improper handling of IMAP FETCH responses when the data size is zero bytes. The deliver-data function may attempt to read data from a buffer that is not properly terminated, potentially leading to reading memory beyond the allocated area.

Multiple integer overflows in the (1) curl_escape, (2) curl_easy_escape, (3) curl_unescape, and (4) curl_easy_unescape functions in libcurl before version 7.50.3 allow attackers to have unspecified impact via a string of length 0xffffffff, which triggers a heap-based buffer overflow.

When libpsl support is enabled, libcurl fails to enforce the Public Suffix List boundary check when processing a Set-Cookie header where the Domain attribute explicitly matches an origin host that is itself a public suffix (e.g., Domain=co.uk set by co.uk). Instead of coercing it into a strict host-only cookie, libcurl saves the cookie with wildcard domain scope (.co.uk), causing the cookie to be sent to arbitrary sibling subdomains under the same public suffix.

In libcurl with the wolfSSL backend, when CA caching is enabled and a CURLOPT_SSL_CTX_FUNCTION callback replaces the trust store, libcurl can silently reinstall the cached store after the callback returns. A certificate trusted by the cached store but rejected by the callback-selected store is then incorrectly accepted.

A flaw in libcurl makes it wrongly reuse an existing HTTPS connection setup for a given hostname even when using a different Native CA Store setting (CURLSSLOPT_NATIVE_CA) than when the connection was created.

When CURLOPT_PINNEDPUBLICKEY is configured alongside options that disable standard peer verification (CURLOPT_SSL_VERIFYPEER = 0 and CURLOPT_SSL_VERIFYHOST = 0), libcurl fails to enforce public key pinning on connections established without a presented server certificate. Bypassing the pinning check under these disabled-verification conditions allows unauthenticated connections to succeed when they should be rejected.

When performing transfers via libcurl's multi interface, pooled TLS connections can outlive their originating easy handles. In OpenSSL 3 provider configurations, libcurl attaches an allocated library context to the easy handle's state and passes it to OpenSSL without acquiring an ownership reference; destroying the easy handle prematurely frees this context while the active connection retains a dangling pointer, leading to a heap-use-after-free upon subsequent I/O or post-handshake operations.

A flaw in libcurl's SASL negotiation for LDAP authentication allows an incomplete handshake sequence to be misinterpreted as a successful cryptographic verification. An attacker executing a Man-in-the-Middle (MITM) attack can inject a premature or shortcut response that bypasses complete peer validation.

A vulnerability in libcurl allows accepting an untrusted server during SCP or SFTP transfers when using the CURLOPT_SSH_KEYFUNCTION callback. The server can present a host key type different from the one recorded in the known_hosts file, and the callback mechanism fails to enforce rejection, allowing the connection to succeed without warning.

In libcurl, the HTTP `Referer:` header persisted even when explicitly cleared. Although the documentation states that passing NULL to `CURLOPT_REFERER` suppresses the header, the option failed to clear the internal state, so the previous referrer string was erroneously reused and sent in subsequent requests.

A vulnerability in libcurl allows sending the second request's data before enforcing certificate verification when SSL session caching and early data are enabled. This occurs when the target server is replaced by an attacker's impostor machine.

Calling `curl_easy_pause()` within the event-based `CURLMOPT_SOCKETFUNCTION` callback triggers a use-after-free vulnerability. libcurl attempts to store a flag using a dangling struct pointer immediately after that pointer's memory has been freed.

libcurl would reuse a previously created connection even when some mTLS config related option had been changed that should have prohibited reuse. Specifically, options related to the private key were left out from the configuration match checks.

libcurl might in some circumstances reuse the wrong connection when asked to do Negotiate-authenticated ones, even when they are set to use different 'services'. Due to a logical error in the code, a request issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different services.

After successfully transferring through a specific HTTP proxy (proxyA) with Digest authentication, changing the proxy host to a second one (proxyB) for a second transfer while reusing the same handle causes libcurl to wrongly pass the Proxy-Authorization header meant for proxyA to proxyB.

When asked to both use a .netrc file for credentials and to follow HTTP redirects, libcurl could leak the password used for the first host to the followed-to host under certain circumstances.

In libcurl, when a custom `Host:` header is first set for an HTTP request and a second request is subsequently made using the same *easy handle* without the custom `Host:` header set, the second request uses stale information and passes on cookies meant for the first host.

libcurl might in some circumstances reuse the wrong connection for SMB(S) transfers. Due to a logical error in the code, a network transfer operation could wrongfully reuse an existing SMB connection to the same server that was using a different share than the new transfer should. This could lead to downloading the wrong file or uploading a file to the wrong place, using the same credentials and server name.

libcurl might in some circumstances reuse the wrong connection when asked to do an authenticated HTTP(S) request after a Negotiate-authenticated one, when both use the same host. A logical error in the code causes a request to wrongfully reuse an existing connection authenticated with different credentials.

A vulnerability exists where a connection requiring TLS incorrectly reuses an existing unencrypted connection from the same connection pool. If an initial transfer is made in clear-text (via IMAP, SMTP, or POP3), a subsequent request to the same host bypasses the TLS requirement and transmits data unencrypted.

libcurl contains a logical error in its connection reuse mechanism. Under certain circumstances, an HTTP or HTTPS request using Negotiate authentication may wrongly reuse an existing connection that was authenticated with different credentials. As a result, a second request with different credentials may be sent over a connection authenticated for the first user.

When doing SSH-based transfers using either SCP or SFTP, and setting the known_hosts file, libcurl could still mistakenly accept connecting to hosts *not present* in the specified file if they were added as recognized in the libssh *global* known_hosts file.

When doing TLS transfers with reused easy or multi handles and altering the CURLSSLOPT_NO_PARTIALCHAIN option, libcurl could accidentally reuse a cached CA store for which the partial chain option was reversed. Contrary to user expectations, libcurl could find and accept a trust chain it otherwise would not.

When doing multi-threaded LDAPS transfers (LDAP over TLS) with libcurl, changing TLS options in one thread inadvertently changed them globally and could affect other concurrently set up transfers. Disabling certificate verification for a specific transfer could unintentionally disable the feature for other threads as well.