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.
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.
incomplete mTLS config matching in conn reuse
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.
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 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.
Last updated 10 July 2026
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.
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.
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.
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.
curl. Multiple issues were addressed by updating to curl version 7.79.1.
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.
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.
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.
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.
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
lib/ssluse.c in cURL and libcurl 7.4 through 7.19.5, when OpenSSL is used, does not properly handle a '\0' character in a domain name in the subject's Common Name (CN) field of an X.509 certificate, which allows man-in-the-middle attackers to spoof arbitrary SSL servers via a crafted certificate issued by a legitimate Certification Authority, a related issue to CVE-2009-2408.
It was found that cURL performed client credentials delegation during the client-to-server GSS security mechanisms negotiation. A remote, rogue server could use this flaw to impersonate the cURL client (victim) against the correct (originally intended) server, potentially leading to denial of cURL tool services for victim client.
cURL and libcurl 7.18.0 through 7.32.0, when built with OpenSSL, disables the certificate CN and SAN name field verification (CURLOPTSSLVERIFYHOST) when the digital signature verification (CURLOPTSSLVERIFYPEER) is disabled, which allows man-in-the-middle attackers to spoof SSL servers via an arbitrary valid certificate.
Heap-based buffer overflow in the curleasyunescape function in lib/escape.c in cURL and libcurl 7.7 through 7.30.0 allows remote attackers to cause a denial of service (application crash) or possibly execute arbitrary code via a crafted string ending in a "%" (percent) character.
A security flaw was found in the way the library of cURL, an utility for retrieval of files from remote servers, performed match of cookie domain names when making a decision if (previously stored cookies) should be sent to particular domain. Due to a bug in match function implementation, (formerly) the decision / match succeeded also in cases, where just suffix / certain part of the domain name matched the domain name, the current request originated from. A remote attacker could use this flaw to possibly hijack the user session of the victim by submitting a request containing a specially-crafted domain name.
References: [1] http://thread.gmane.org/gmane.comp.web.curl.library/38986
Acknowledgements:
Red Hat would like to thank the cURL project for reporting this issue. Upstream acknowledges YAMADA Yasuharu as the original reporter.
Stack-based buffer overflow in the Curlsaslcreatedigestmd5message function in lib/curlsasl.c in curl and libcurl 7.26.0 through 7.28.1, when negotiating SASL DIGEST-MD5 authentication, allows remote attackers to cause a denial of service (crash) and possibly execute arbitrary code via a long string in the realm parameter in a (1) POP3, (2) SMTP or (3) IMAP message.
The darwinsslconnectstep1 function in lib/vtls/curldarwinssl.c in libcurl 7.31.0 through 7.39.0, when using the DarwinSSL (aka SecureTransport) back-end for TLS, does not check if a cached TLS session validated the certificate when reusing the session, which allows man-in-the-middle attackers to spoof servers via a crafted certificate.
CRLF injection vulnerability in libcurl 6.0 through 7.x before 7.40.0, when using an HTTP proxy, allows remote attackers to inject arbitrary HTTP headers and conduct HTTP response splitting attacks via CRLF sequences in a URL.
The curleasyduphandle function in libcurl 7.17.1 through 7.38.0, when running with the CURLOPTCOPYPOSTFIELDS option, does not properly copy HTTP POST data for an easy handle, which triggers an out-of-bounds read that allows remote web servers to read sensitive memory information.
cURL and libcurl before 7.38.0 does not properly handle IP addresses in cookie domain names, which allows remote attackers to set cookies for or send arbitrary cookies to certain sites, as demonstrated by a site at 192.168.0.1 setting cookies for a site at 127.168.0.1.
cURL and libcurl before 7.38.0 allow remote attackers to bypass the Same Origin Policy and set cookies for arbitrary sites by setting a cookie for a top-level domain.