libcurl had a flaw that when instructed to clear proxy authentication credentials which made it not do so, leaving the old credentials around to get used for subsequent transfers that should not know nor use them.

When reusing a libcurl handle for sequential transfers driven by environment-variable proxy configuration, libcurl fails to clear the proxy authentication state between requests. Specifically, if the initial transfer authenticates against proxyA using Digest auth, a subsequent transfer routed through proxyB erroneously leaks the Proxy-Authorization: header intended solely for proxyA.

In this scenario, libcurl first uses a proper HTTP/3 server for the initial transfers, and when it makes a second transfer to the same site it has been replaced by the attacker's impostor machine - without a valid certificate.

When libcurl returns to the hostname the second time with a cached SSL session (CURLOPTSSLSESSIONIDCACHE is not disabled) and early data enabled (the CURLSSLOPTEARLYDATA bit is set in CURLOPTSSLOPTIONS), libcurl might send off the second request's bytes on that new connection before enforcing the certificate verification failure. Potentially leaking sensitive information.

When a libcurl-based application performs transfers via SCP:// or SFTP:// and utilizes the CURLOPTSSHKEYFUNCTION callback, it may silently accept an untrusted server. This vulnerability occurs when a server presents a host key type that does not match the specific key type already recorded for that host in the knownhosts file. Instead of rejecting the mismatch, the callback mechanism fails to properly enforce the restriction, allowing the connection to succeed without warning and risking a potential man-in-the-middle attack.

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.

incomplete mTLS config matching in conn reuse

Last updated 10 July 2026

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.

libcurl can in some circumstances reuse the wrong connection when asked to do an Negotiate-authenticated HTTP or HTTPS request.

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 criterion must first 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 credentials. One underlying reason being that Negotiate sometimes authenticates connections and not requests, contrary to how HTTP is designed to work.

An application that allows Negotiate authentication to a server (that responds wanting Negotiate) with user1:password1 and then does another operation to the same server also using Negotiate but with user2:password2 (while the previous connection is still alive) - the second request wrongly reused the same connection and since it then sees that the Negotiate negotiation is already made, it just sends the request over that connection thinking it uses the user2 credentials when it is in fact still using the connection authenticated for user1...

The set of authentication methods to use is set with CURLOPTHTTPAUTH.

Applications can disable libcurl's reuse of connections and thus mitigate this problem, by using one of the following libcurl options to alter how connections are or are not reused: CURLOPTFRESHCONNECT, CURLOPTMAXCONNECTS and CURLMOPTMAXHOSTCONNECTIONS (if using the curlmulti API).

When using CURLOPTPINNEDPUBLICKEY option with libcurl or --pinnedpubkey with the curl tool,curl should check the public key of the server certificate to verify the peer.

This check was skipped in a certain condition that would then make curl allow the connection without performing the proper check, thus not noticing a possible impostor. To skip this check, the connection had to be done with QUIC with ngtcp2 built to use GnuTLS and the user had to explicitly disable the standard certificate verification.

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-using application.

The libcurl CURLOPTSSLVERIFYPEER option was disabled on a subset of requests made by Nest production devices which enabled a potential man-in-the-middle attack on requests to Google cloud services by any host the traffic was routed through.

cURL libcurl is vulnerable to a denial of service, caused by a memory allocation flaw in the utf8asn1str() function in the ASN1 parser. By using a specially crafted TLS certificate, a remote attacker could exploit this vulnerability to cause a denial of service condition.

On October 11, 2023, cURL released Version 8.4.0 of the cURL utility and the libcurl library. This release addressed two security vulnerabilities: CVE-2023-38545 - High Security Impact Rating (SIR)CVE-2023-38546 - Low SIRThis

REJECT We issued this CVE pre-maturely, as we have subsequently realized that this issue points out a problem that there really is no safe measures around or protections for.

curl. Multiple issues were addressed by updating to curl version 7.79.1.

A flaw was found in libcurl in the way libcurl handles previously used connections without accounting for 'issuer cert' and comparing the involved paths case-insensitively. This flaw allows libcurl to use the wrong connection. The highest threat from this vulnerability is to confidentiality.

A flaw was found in the way libcurl handled TLS 1.3 session tickets. A malicious HTTPS proxy could possibly use this flaw to make libcurl resume a TLS session it previously had with the proxy while intending to resume a TLS session with a target server, making it possible for the proxy to perform a man-in-the-middle attack.

curl 7.1.1 to and including 7.75.0 is vulnerable to an "Exposure of Private Personal Information to an Unauthorized Actor" by leaking credentials in the HTTP Referer: header. libcurl does not strip off user credentials from the URL when automatically populating the Referer: HTTP request header field in outgoing HTTP requests, and therefore risks leaking sensitive data to the server that is the target of the second HTTP request.

curl 7.41.0 through 7.73.0 is vulnerable to an improper check for certificate revocation due to insufficient verification of the OCSP response.

A flaw was found in libcurl from versions 7.29.0 through 7.71.1. An application that performs multiple requests with libcurl's multi API, and sets the CURLOPTCONNECTONLY option, might experience libcurl using the wrong connection. The highest threat from this vulnerability is to data confidentiality.

curl and libcurl before 7.57.0 on 32-bit platforms allow attackers to cause a denial of service (out-of-bounds access and application crash) or possibly have unspecified other impact because too little memory is allocated for interfacing to an SSL library.

When asking to get a file from a file:// URL, libcurl provides a feature that outputs meta-data about the file using HTTP-like headers. The code doing this would send the wrong buffer to the user (stdout or the application's provide callback), which could lead to other private data from the heap to get inadvertently displayed. The wrong buffer was an uninitialized memory area allocated on the heap and if it turned out to not contain any zero byte, it would continue and display the data following that buffer in memory.

It was found that the fix for CVE-2015-3148 did not correctly backported to curl in RHEL 6 because it did not reflect the fact that the HAVEGSSAPI define was meanwhile substituted by USEHTTPNEGOTIATE.

The original issue was described as:

It was discovered that libcurl could incorrectly reuse Negotiate authenticated HTTP connections for subsequent requests. If an application using libcurl established a Negotiate authenticated HTTP connection to a server and sent subsequent requests with different credentials, the connection could be re-used with the initial set of credentials instead of using the new ones.

This issue was introduced in RHEL 6.7 and affects RHEL 6 curl only.

It was found that provided string length arguments in four libcurl functions curlescape(), curleasyescape(), curlunescape and curleasyunescape were not properly checked and due to arithmetic in the functions, passing in the length 0xffffffff (2^32-1 or UINTMAX or even just -1) would end up causing an allocation of zero bytes of heap memory that curl would attempt to write gigabytes of data into.

This flaw does not affect the curl command line tool.

Affected versions: libcurl 7.11.1 to and including 7.50.2

External References:

https://curl.haxx.se/docs/adv20160914.html

cURL and libcurl 7.40.0 through 7.42.1 send the HTTP Basic authentication credentials for a previous connection when reusing a reset (curleasyreset) connection handle to send a request to the same host name, which allows remote attackers to obtain sensitive information via unspecified vectors.

The smbrequeststate function in cURL and libcurl 7.40.0 through 7.42.1 allows remote SMB servers to obtain sensitive information from memory or cause a denial of service (out-of-bounds read and crash) via crafted length and offset values.

The default configuration for cURL and libcurl before 7.42.1 sends custom HTTP headers to both the proxy and destination server, which might allow remote proxy servers to obtain sensitive information by reading the header contents.

cURL and libcurl 7.10.6 through 7.41.0 does not properly re-use NTLM connections, which allows remote attackers to connect as other users via an unauthenticated request, a similar issue to CVE-2014-0015.

The fixhostname function in cURL and libcurl 7.37.0 through 7.41.0 does not properly calculate an index, which allows remote attackers to cause a denial of service (out-of-bounds read or write and crash) or possibly have other unspecified impact via a zero-length host name, as demonstrated by "http://:80" and ":80."