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'.
libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead.
When reusing a connection a range of criteria must be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different services.
Music Player Daemon (MPD) before version 0.24.11 contains a server-side request forgery vulnerability in CurlInputPlugin where CURLOPTFOLLOWLOCATION is set without CURLOPTREDIRPROTOCOLSSTR, allowing unauthenticated attackers to bypass the http/https scheme restriction by causing a malicious HTTP server to redirect to non-HTTP protocols such as gopher, ftp, sftp, ldap, dict, rtmp, or rtsp. Attackers can trigger this vulnerability via MPD commands that initiate URL fetches, including add, readcomments, albumart, readpicture, or load, to interact with internal or restricted network services on systems running libcurl versions prior to 7.85.0.
When doing multi-threaded LDAPS transfers (LDAP over TLS) with libcurl, changing TLS options in one thread would inadvertently change them globally and therefore possibly also affect other concurrently setup transfers.
Disabling certificate verification for a specific transfer could unintentionally disable the feature for other threads as well.
libcurl wrongly allows cookies to be set for Top Level Domains (TLDs) if thehost name is provided with a trailing dot.curl can be told to receive and send cookies. curl's "cookie engine" can bebuilt with or without Public Suffix Listawareness. If PSL support not provided, a more rudimentary check exists to atleast prevent cookies from being set on TLDs. This check was broken if thehost name in the URL uses a trailing dot.This can allow arbitrary sites to set cookies that then would get sent to adifferent and unrelated site or domain.
Due to use of a dangling pointer, libcurl 7.29.0 through 7.71.1 can use the wrong connection when sending data.
libcurl keeps previously used connections in a connection pool for subsequent transfers to reuse if one of them matches the setup.
An easy handle that first uses default native CA trust can continue trusting the native platform store after the application switches that same handle to custom CA material for a later transfer.
libcurl would reuse a previously created connection even when some mTLS config related option had been changed that should have prohibited reuse.
libcurl keeps previously used connections in a connection pool for subsequent transfers to reuse if one of them matches the setup. However, some TLS settings related to client certificates were left out from the configuration match checks, making them match too easily. In particular options related to the private key.
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 makes it wrongly reuse an HTTP connection setup for a given hostname using Negotiate authentication, when the initial request is done using empty credentials. This can make user B's request get sent over user A's previously authenticated connection.
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). Consequently, the cookie is inappropriately included in subsequent outbound requests or HTTP redirects to arbitrary sibling subdomains under the same public suffix (e.g., attacker.co.uk).
An issue in curl’s QUIC UDP receive function allows a malicious HTTP/3 server to trigger a remote denial of service against a curl or libcurl client. Because the helper function discards zero-length UDP datagrams before counting them toward the per-call packet budget, a connected QUIC peer can continuously stream empty datagrams to indefinitely stall the client.
A vulnerability in libcurl caused the HTTP Referer: header to persist even when explicitly cleared. While the documentation states that passing NULL to CURLOPTREFERER suppresses the header, the option failed to clear the internal state. As a result, the previous referrer string was erroneously reused and sent in subsequent requests, potentially leaking sensitive information to unintended servers.
Successfully using libcurl to do a transfer to a specific HTTP origin (hostA) with Digest authentication and then changing the origin to a different one (hostB) for a second transfer, reusing the same handle, makes libcurl wrongly pass on the Authorization: header field meant for hostA, to hostB.
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".
libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead.
When reusing a connection a range of criteria must be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different services.
Successfully using libcurl to do a transfer to a specific HTTP origin (hostA) with Digest authentication and then changing the origin to a different one (hostB) for a second transfer, reusing the same handle, makes libcurl wrongly pass on the Authorization: header field meant for hostA, to hostB.
auto client cert connection reuse mixup
An ftp:// transfer configured with CURLUSESSLNONE can reuse a pooled FTP control connection that a previous easy handle upgraded with STARTTLS and authenticated using a client certificate. The second handle performs neither a new TLS handshake nor a new FTP login, so the server continues to authorize it under the first handle's certificate identity.
libcurl's ASN1 parser has this utf8asn1str() function used for parsing an ASN.1 UTF-8 string. Itcan detect an invalid field and return error. Unfortunately, when doing so it also invokes free() on a 4 byte localstack buffer. Most modern malloc implementations detect this error and immediately abort. Some however accept the input pointer and add that memory to its list of available chunks. This leads to the overwriting of nearby stack memory. The content of the overwrite is decided by the free() implementation; likely to be memory pointers and a set of flags. The most likely outcome of exploting this flaw is a crash, although it cannot be ruled out that more serious results can be had in special circumstances.
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 CURLINFOCERTINFO (https://curl.se/libcurl/c/CURLINFOCERTINFO.html) is used.
gzip integer overflow
eventfd double close
A flaw was found in libcurl. An application using libcurl that performs an authenticated HTTP(S) request after a Negotiate-authenticated one to the same host may incorrectly reuse the previous connection. This authentication bypass vulnerability allows the second request to be sent over a connection authenticated with different credentials, potentially leading to unauthorized access or information disclosure.
cross-proxy Digest auth state leak
A flaw was found in libcurl. An application using libcurl that performs an authenticated HTTP(S) request after a Negotiate-authenticated one to the same host may incorrectly reuse the previous connection. This authentication bypass vulnerability allows the second request to be sent over a connection authenticated with different credentials, potentially leading to unauthorized access or information disclosure.
Successfully using libcurl to do a transfer over a specific HTTP proxy (proxyA) with Digest authentication and then changing the proxy host to a second one (proxyB) for a second transfer, reusing the same handle, makes libcurl wrongly pass on the Proxy-Authorization: header field meant for proxyA, to proxyB.
A flaw was found in libcurl. When configured to use a .netrc file for credentials and follow HTTP redirects, libcurl can inadvertently send the password from the initial connection to the redirected host. This sensitive information disclosure occurs when both the original and redirect URLs use clear text HTTP, are performed over the same HTTP proxy, and the same connection is reused. This vulnerability, categorized as an Exposure of Sensitive Information to an Unauthorized Actor (CWE-200), could allow an attacker to obtain user credentials.
A flaw was found in libcurl. When configured to use a .netrc file for credentials and follow HTTP redirects, libcurl can inadvertently send the password from the initial connection to the redirected host. This sensitive information disclosure occurs when both the original and redirect URLs use clear text HTTP, are performed over the same HTTP proxy, and the same connection is reused. This vulnerability, categorized as an Exposure of Sensitive Information to an Unauthorized Actor (CWE-200), could allow an attacker to obtain user credentials.
stale custom cookie host causes cookie leak
Last updated 10 July 2026
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, failing to specify that it does not for QUIC and HTTP/3. Since pinning makes the transfer succeed if the pin is fine, users could unwittingly connect to an impostor server without noticing.