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 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.
curl. Multiple issues were addressed by updating to curl version 7.79.1.
Last updated 10 July 2026
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."
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.
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.
incomplete mTLS config matching in conn reuse
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.
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.
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.
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.
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.
The sanitizecookiepath function in cURL and libcurl 7.31.0 through 7.41.0 does not properly calculate an index, which allows remote attackers to cause a denial of service (out-of-bounds write and crash) or possibly have other unspecified impact via a cookie path containing only a double-quote character.
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.
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.
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.
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
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.
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.
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 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.
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.
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.
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.
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.
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.
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.