CVE-2026-1965: bad reuse of HTTP Negotiate connection
bad reuse of HTTP Negotiate connection
Other sources
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).
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Ensure CURLOPT_HTTPAUTH is set to the intended authentication method(s) so that HTTP Negotiate is used consistently for requests; this mitigates bad reuse of Negotiate-authenticated connections when the wrong authentication method is used.
libcurl CURLOPT_HTTPAUTH - Configuration
Set CURLOPT_MAXCONNECTS to control connection reuse and avoid reusing the wrong HTTP Negotiate-authenticated connection.
libcurl CURLOPT_MAXCONNECTS - Configuration
If using the curl_multi API, set CURLMOPT_MAX_HOST_CONNECTIONS to limit per-host connection reuse and mitigate bad reuse of HTTP Negotiate connections.
libcurl CURLMOPT_MAX_HOST_CONNECTIONS - Configuration
Use CURLOPT_FRESH_CONNECT to prevent reusing an existing connection (forcing a fresh connection) and avoid incorrect reuse of an HTTP Negotiate connection.
libcurl CURLOPT_FRESH_CONNECT
Event History
Frequently Asked Questions
What is the severity of CVE-2026-1965?
CVE-2026-1965 is considered a moderate severity vulnerability due to potential unauthorized access from incorrect connection reuse.
How do I fix CVE-2026-1965?
To fix CVE-2026-1965, you should upgrade your version of libcurl to the latest release that addresses this vulnerability.
What applications are affected by CVE-2026-1965?
CVE-2026-1965 primarily affects applications that use the redhat/libcurl library for handling HTTP requests.
What kind of attacks can CVE-2026-1965 lead to?
CVE-2026-1965 can potentially enable attackers to perform authentication bypass and other security breaches due to connection mismanagement.
Is CVE-2026-1965 easy to exploit?
Exploitation of CVE-2026-1965 may vary depending on the implementation but generally requires specific conditions related to Negotiate authentication.