libcurl vulnerabilities

A flaw in libcurl allows an attacker to insert cookies at will into a running program if specific conditions are met. When an easy handle with cookies enabled is duplicated via curl_easy_duphandle and the source handle did not read cookies from a file, the cloned handle stores the filename as "none", potentially causing inadvertent loading of cookies from a file named "none" in the current directory.

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.

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.

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.

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.

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.

When an FTP wildcard LIST operation fails, libcurl omits the restoration path meant for successful listings, leaving the write callback set to the internal listing parser and the write callback data pointing directly to the easy handle. Subsequent reuse of this handle triggers an immediate crash, and cloning it via curl_easy_duphandle() copies this corrupted state into the duplicate. If the original handle is subsequently freed, executing a transfer on the cloned handle causes a heap use-after-free read; alternatively, reusing the original or cloned handle while changing only CURLOPT_WRITEDATA results in type confusion.

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.

libcurl's ASN1 parser code has the `GTime2str()` function, used for parsing an ASN.1 Generalized Time field. If given an syntactically incorrect field, the parser might end up using -1 for the length of the *time fraction*, leading to a `strlen()` getting performed on a pointer to a heap buffer area that is not (purposely) null terminated. This flaw most likely leads to a crash, but can also lead to heap contents getting returned to the application when CURLINFO_CERTINFO is used.

When an application tells libcurl it wants to allow HTTP/2 server push, and the amount of received headers for the push surpasses the maximum allowed limit (1000), libcurl aborts the server push. When aborting, libcurl inadvertently does not free all the previously allocated headers and instead leaks the memory. Further, this error condition fails silently and is therefore not easily detected by an application.

When sending data to an MQTT server, libcurl <= 7.73.0 and 7.78.0 could in some circumstances erroneously keep a pointer to an already freed memory area and both use that again in a subsequent call to send data and also free it *again*.

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 keeps previously used connections in a pool for reuse if one matches the setup. Due to logic errors, the config matching function ignored 'issuercert' and compared paths case-insensitively, which could lead to libcurl reusing wrong connections.

Due to use of a dangling pointer, libcurl 7.29.0 through 7.71.1 can use the wrong connection when sending data.

An integer overflow in curl's URL API results in a buffer overflow in libcurl 7.62.0 through 7.64.1.

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.

libcurl could accidentally return a URL for curl_easy_getinfo()'s CURLINFO_EFFECTIVE_URL option containing credentials, even though neither the URL provided to libcurl nor the redirected URL did.

A deeply nested multipart MIME structure constructed via the public API causes a stack overflow in libcurl during normal cleanup operations. An excessive recursion depth within curl_mime_free leads to unbounded stack frame allocation during structure traversal, ultimately crashing the host process.

libcurl's TFTP state machine fails to validate state transitions against the requested transfer direction, accepting opening server responses for both reads and writes interchangeably. A malicious TFTP server can respond to a download request in a way that forces the client into transmit mode, prompting libcurl to consume and transmit data from the handle's persistent CURLOPT_READDATA pointer, including data remaining from unrelated prior operations such as an HTTP POST request executed on a reused handle.

By permanently omitting the final control-response line, a malicious FTP, IMAP, POP3, or SMTP server can exploit libcurl and completely bypass its configured transfer timeout mechanism, indefinitely blocking all concurrent transfers bound to the same multi-handle.

When libcurl uses libssh2 with a hashed known_hosts file, an unrelated initial entry can cause host key validation to report a key mismatch as a missing key to the CURLOPT_SSH_KEYFUNCTION callback.

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.