libcurl contains a heap buffer overflow in the function (tftp_receive_packet()) that receives data from a TFTP server. It can call recvfrom() with the default size for the buffer rather than with the size that was used to allocate it. Thus, the content that might overwrite the heap memory is controlled by the server. This flaw is only triggered if the TFTP server sends an OACK without the BLKSIZE option, when a BLKSIZE smaller than 512 bytes was requested by the TFTP client. OACK is a TFTP extension and is not used by all TFTP servers.
libcurl can be told to use kerberos over FTP to a server, as set with the CURLOPT_KRBLEVEL option. During such kerberos FTP data transfer, the server sends data to curl in blocks with the 32 bit size of each block first and then that amount of data immediately following. A malicious or just broken server can claim to send a very large block and if by doing that it makes curl's subsequent call to realloc() to fail, curl would then misbehave in the exit path and double-free the memory. In practical terms, an up to 4 GB memory area may very well be fine to allocate on a modern 64 bit system but on 32 bit systems it will fail.
A non-privileged user or program can put code and a config file in a known non-privileged path (under C:/usr/local/) that will make curl automatically run the code (as an openssl "engine") on invocation. If that curl is invoked by a privileged user it can do anything it wants. This flaw exists in the official curl-for-windows binaries built and hosted by the curl project (all versions up to and including 7.65.1_1). It does not exist in the curl executable shipped by Microsoft, bundled with Windows 10. It possibly exists in other curl builds for Windows too that uses OpenSSL.
libcurl contains a heap buffer overflow in the function (`tftp_receive_packet()`) that recevives data from a TFTP server. It calls `recvfrom()` with the default size for the buffer rather than with the size that was used to allocate it. Thus, the content that might overwrite the heap memory is entirely controlled by the server. The flaw exists if the user selects to use a "blksize" of 504 or smaller (default is 512). The smaller size that is used, the larger the possible overflow becomes. Users chosing a smaller size than default should be rare as the primary use case for changing the size is to make it larger.
libcurl contains two integer overflows in the curl_url_set() function that if triggered, can lead to a too small buffer allocation and a subsequent heap buffer overflow. The flaws only exist on 32 bit architectures and require excessive string input lengths.
libcurl contains a heap out-of-bounds read in the code handling the end-of-response for SMTP. If the buffer passed to smtp_endofresp() isn't NUL terminated and contains no character ending the parsed number, and len is set to 5, then the strtol() call reads beyond the allocated buffer. The read contents will not be returned to the caller.
libcurl contains a stack based buffer overflow vulnerability. The function creating an outgoing NTLM type-3 header (`lib/vauth/ntlm.c:Curl_auth_create_ntlm_type3_message()`), generates the request HTTP header contents based on previously received data. The check that exists to prevent the local buffer from getting overflowed is implemented wrongly (using unsigned math) and as such it does not prevent the overflow from happening. This output data can grow larger than the local buffer if very large "nt response" data is extracted from a previous NTLMv2 header provided by the malicious or broken HTTP server. Such a "large value" needs to be around 1000 bytes or more. The actual payload data copied to the target buffer comes from the NTLMv2 type-2 response header.
libcurl contains a heap buffer out-of-bounds read flaw. The function handling incoming NTLM type-2 messages (lib/vauth/ntlm.c:ntlm_decode_type2_target) does not validate incoming data correctly and is subject to an integer overflow vulnerability. Using that overflow, a malicious or broken NTLM server could trick libcurl to accept a bad length + offset combination that would lead to a buffer read out-of-bounds.