CVE-2026-1965
MediumCVSS 6.5Exploitation Probability (EPSS)
Low risk18th percentile - higher than 18% of all known CVEs
Summary
libcurl contains a logical error in its connection reuse mechanism. Under certain circumstances, an HTTP or HTTPS request using Negotiate authentication may wrongly reuse an existing connection that was authenticated with different credentials. As a result, a second request with different credentials may be sent over a connection authenticated for the first user.
Risk Assessment
An application may send a request with user2 credentials over a connection authenticated as user1, leading to unauthorized access to resources or actions performed under the wrong account. This poses a risk to confidentiality, integrity, and access control enforcement.
Recommendation
Update libcurl to a version containing the fix for this flaw. If updating is not possible, disable connection reuse by setting the CURLOPT_FRESH_CONNECT, CURLOPT_MAXCONNECTS, or CURLMOPT_MAX_HOST_CONNECTIONS options (when using the curl_multi API).
Other vulnerabilities in libcurl
See all- CVE-2023-38546Low
A flaw in libcurl allows an attacker to insert cookies at will into a running program if specific conditions are met. When an easy handle with cookies enabled is duplicated via curl_easy_duphandle and the source handle did not read cookies from a file, the cloned handle stores the filename as "none", potentially causing inadvertent loading of cookies from a file named "none" in the current directory.
- CVE-2017-1000254High
libcurl may read outside of a heap allocated buffer when doing FTP. A flaw in the string parser for the directory name may lead to a missing NUL byte at the end of the buffer, resulting in the potential to read data beyond the allocated memory area.
- CVE-2016-5421High
Use-after-free vulnerability in libcurl before version 7.50.1 allows attackers to control which connection is used or possibly have unspecified other impact via unknown vectors.
- CVE-2016-0755High
The ConnectionExists function in lib/url.c in libcurl before version 7.47.0 does not properly re-use NTLM-authenticated proxy connections, which might allow remote attackers to authenticate as other users via a request.
- CVE-2025-5399Medium
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.
- CVE-2025-4947Medium
libcurl accidentally skips certificate verification for QUIC connections when connecting to a host specified as an IP address in the URL. Therefore, it does not detect impostors or man-in-the-middle attacks.
- CVE-2024-6874Medium
The curl_url_get() function in libcurl offers punycode conversions to and from IDN. When converting a name that is exactly 256 bytes, libcurl reads outside a stack-based buffer when built with the macidn IDN backend.
- CVE-2024-6197High
libcurl's ASN1 parser has this utf8asn1str() function used for parsing an ASN.1 UTF-8 string. It can detect an invalid field and return error. Unfortunately, when doing so it also invokes `free()` on a 4 byte local stack buffer. Most modern malloc implementations detect this error and immediately abort.
- CVE-2025-5025Medium
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, but fails to specify that it does not for QUIC.
- CVE-2026-92388Critical
When an FTP wildcard LIST operation fails, libcurl omits the restoration path meant for successful listings, leaving the write callback set to the internal listing parser and the write callback data pointing directly to the easy handle. Subsequent reuse of this handle triggers an immediate crash, and cloning it via curl_easy_duphandle() copies this corrupted state into the duplicate. If the original handle is subsequently freed, executing a transfer on the cloned handle causes a heap use-after-free read; alternatively, reusing the original or cloned handle while changing only CURLOPT_WRITEDATA results in type confusion.
Original NVD description (English source)
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 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 `CURLOPT_HTTPAUTH`. 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: `CURLOPT_FRESH_CONNECT`, `CURLOPT_MAXCONNECTS` and `CURLMOPT_MAX_HOST_CONNECTIONS` (if using the curl_multi API).
Vulnerability data from NVD (NIST) · CISA KEV · EPSS