CVE-2026-1965

libcurl can in some circumstances reuse the wrong connection when asked to do<br /> an Negotiate-authenticated HTTP or HTTPS request.<br /> <br /> libcurl features a pool of recent connections so that subsequent requests can<br /> reuse an existing connection to avoid overhead.<br /> <br /> When reusing a connection a range of criterion must first be met. Due to a<br /> logical error in the code, a request that was issued by an application could<br /> wrongfully reuse an existing connection to the same server that was<br /> authenticated using different credentials. One underlying reason being that<br /> Negotiate sometimes authenticates *connections* and not *requests*, contrary<br /> to how HTTP is designed to work.<br /> <br /> An application that allows Negotiate authentication to a server (that responds<br /> wanting Negotiate) with `user1:password1` and then does another operation to<br /> the same server also using Negotiate but with `user2:password2` (while the<br /> previous connection is still alive) - the second request wrongly reused the<br /> same connection and since it then sees that the Negotiate negotiation is<br /> already made, it just sends the request over that connection thinking it uses<br /> the user2 credentials when it is in fact still using the connection<br /> authenticated for user1...<br /> <br /> The set of authentication methods to use is set with `CURLOPT_HTTPAUTH`.<br /> <br /> Applications can disable libcurl&amp;#39;s reuse of connections and thus mitigate this<br /> problem, by using one of the following libcurl options to alter how<br /> connections are or are not reused: `CURLOPT_FRESH_CONNECT`,<br /> `CURLOPT_MAXCONNECTS` and `CURLMOPT_MAX_HOST_CONNECTIONS` (if using the<br /> curl_multi API).