CVE-2026-1965

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).

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).

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 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).

cURL is a computer software project providing a library (libcurl) and command-line tool (curl) for transferring data using various protocols.

Security Fix(es):

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 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).(CVE-2026-1965)

When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer performs a redirect to a second URL, curl could leak that token to the second hostname under some circumstances.

If the hostname that the first request is redirected to has information in the used .netrc file, with either of the machine or default keywords, curl would pass on the bearer token set for the first host also to the second one.(CVE-2026-3783)

curl would wrongly reuse an existing HTTP proxy connection doing CONNECT to a server, even if the new request uses different credentials for the HTTP proxy. The proper behavior is to create or use a separate connection.(CVE-2026-3784)

The curl packages provide the libcurl library and the curl utility for downloading files from servers using various protocols, including HTTP, FTP, and LDAP.

Security Fix(es):

• curl: curl: Authentication bypass due to incorrect connection reuse with Negotiate authentication (CVE-2026-1965)

• curl: curl: Information disclosure via OAuth2 bearer token leakage during HTTP(S) redirect (CVE-2026-3783)

• curl: curl: Man-in-the-middle attack via SSH host key bypass (CVE-2026-9547)

• curl: curl: Insecure connection establishment due to TLS configuration mismatch (CVE-2026-8286)

For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

Root has patched CVE-2026-1965 in the curl package for Root:Debian:11. Multiple fixed versions available.

Root has patched CVE-2026-1965 in the curl package for Root:Debian:12. Multiple fixed versions available.

Root has patched CVE-2026-1965 in the rootio-curl package for Root:Debian:13. Multiple fixed versions available.

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).

The curl packages provide the libcurl library and the curl utility for downloading files from servers using various protocols, including HTTP, FTP, and LDAP.

Security Fix(es):

• curl: curl: Authentication bypass due to incorrect connection reuse with Negotiate authentication (CVE-2026-1965)
• curl: curl: Information disclosure via OAuth2 bearer token leakage during HTTP(S) redirect (CVE-2026-3783)
• curl: curl: Man-in-the-middle attack via SSH host key bypass (CVE-2026-9547)
• curl: curl: Insecure connection establishment due to TLS configuration mismatch (CVE-2026-8286)

For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

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).

• CVE-2026-1965: fix incorrect connection reuse; prevent reuse of Negotiate- authenticated connections with different credentials and require authentication identity match
• CVE-2026-3784: fix wrong proxy connection reuse with different credentials; check proxy user/password in proxy_info_matches to prevent reuse of HTTP proxy CONNECT connections when credentials differ
• CVE-2026-3783: prevent bearer token leak on HTTP(S) redirect when .netrc contains entries for the redirected host

• CVE-2026-1965: fix incorrect connection reuse; prevent reuse of Negotiate- authenticated connections with different credentials and require authentication identity match
• CVE-2026-3784: fix wrong proxy connection reuse with different credentials; check proxy user/password in proxy_info_matches to prevent reuse of HTTP proxy CONNECT connections when credentials differ
• CVE-2026-3783: prevent bearer token leak on HTTP(S) redirect when .netrc contains entries for the redirected host

• SECURITY UPDATE: reuse of connections using HTTP Negotiate
  • debian/patches/CVE-2026-1965.patch: fix reuse of connections using HTTP Negotiate and fix copy and paste url_match_auth_nego mistake.
  • CVE-2026-1965
• Bearer token sent without checking auth is allowed
  • debian/patches/CVE-2026-3783.patch: only send bearer if auth is allowed.
  • CVE-2026-3783
• Proxy credential reuse across different credentials
  • debian/patches/CVE-2026-3784.patch: compare proxy credentials in proxy_info_matches to prevent connection reuse with wrong auth.
  • CVE-2026-3784

• CVE-2026-1965: fix incorrect connection reuse; prevent reuse of Negotiate- authenticated connections with different credentials and require authentication identity match
• CVE-2026-3784: fix wrong proxy connection reuse with different credentials; check proxy user/password in proxy_info_matches to prevent reuse of HTTP proxy CONNECT connections when credentials differ
• CVE-2026-3783: prevent bearer token leak on HTTP(S) redirect when .netrc contains entries for the redirected host

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).

These are all security issues fixed in the curl-8.19.0-1.1 package on the GA media of openSUSE Tumbleweed.

This update for curl fixes the following issues:

• CVE-2026-1965: bad reuse of HTTP Negotiate connection (bsc#1259362).
• CVE-2026-3783: token leak with redirect and netrc (bsc#1259363).
• CVE-2026-3784: wrong proxy connection reuse with credentials (bsc#1259364).
• CVE-2026-3805: use after free in SMB connection reuse (bsc#1259365).

This update for curl fixes the following issues:

• CVE-2026-1965: bad reuse of HTTP Negotiate connection (bsc#1259362).
• CVE-2026-3783: token leak with redirect and netrc (bsc#1259363).
• CVE-2026-3784: wrong proxy connection reuse with credentials (bsc#1259364).
• CVE-2026-3805: use after free in SMB connection reuse (bsc#1259365).

This update for curl fixes the following issues:

• CVE-2026-1965: bad reuse of HTTP Negotiate connection (bsc#1259362).
• CVE-2026-3783: token leak with redirect and netrc (bsc#1259363).
• CVE-2026-3784: wrong proxy connection reuse with credentials (bsc#1259364).
• CVE-2026-3805: use after free in SMB connection reuse (bsc#1259365).

This update for curl fixes the following issues:

• CVE-2026-1965: bad reuse of HTTP Negotiate connection (bsc#1259362).
• CVE-2026-3783: token leak with redirect and netrc (bsc#1259363).
• CVE-2026-3784: wrong proxy connection reuse with credentials (bsc#1259364).
• CVE-2026-3805: use after free in SMB connection reuse (bsc#1259365).

This update for curl fixes the following issues:

• CVE-2026-1965: bad reuse of HTTP Negotiate connection (bsc#1259362).
• CVE-2026-3783: token leak with redirect and netrc (bsc#1259363).
• CVE-2026-3784: wrong proxy connection reuse with credentials (bsc#1259364).
• CVE-2026-3805: use after free in SMB connection reuse (bsc#1259365).

This update for curl fixes the following issues:

• CVE-2026-1965: bad reuse of HTTP Negotiate connection (bsc#1259362).
• CVE-2026-3783: token leak with redirect and netrc (bsc#1259363).
• CVE-2026-3784: wrong proxy connection reuse with credentials (bsc#1259364).

This update for curl fixes the following issues:

Security issues fixed:

• CVE-2026-4873: connection reuse ignores TLS requirement (bsc#1262631).
• CVE-2026-5545: wrong reuse of HTTP Negotiate connection (bsc#1262632).
• CVE-2026-6253: proxy credentials leak over redirect-to proxy (bsc#1262635).
• CVE-2026-6276: stale custom cookie host causes cookie leak (bsc#1262636).
• CVE-2026-6429: netrc credential leak with reused proxy connection (bsc#1262638).

Other updates and bugfixes:

• sws: prevent 'connection monitor' to say disconnect twice (bsc#1259362).

This update for curl fixes the following issues:

Security issues fixed:

• CVE-2026-4873: connection reuse ignores TLS requirement (bsc#1262631).
• CVE-2026-5545: wrong reuse of HTTP Negotiate connection (bsc#1262632).
• CVE-2026-6253: proxy credentials leak over redirect-to proxy (bsc#1262635).
• CVE-2026-6276: stale custom cookie host causes cookie leak (bsc#1262636).
• CVE-2026-6429: netrc credential leak with reused proxy connection (bsc#1262638).

Other updates and bugfixes:

• sws: prevent 'connection monitor' to say disconnect twice (bsc#1259362).

This update for curl fixes the following issues:

• CVE-2026-1965: bad reuse of HTTP Negotiate connection (bsc#1259362).
• CVE-2026-3783: token leak with redirect and netrc (bsc#1259363).
• CVE-2026-3784: wrong proxy connection reuse with credentials (bsc#1259364).
• CVE-2026-3805: use after free in SMB connection reuse (bsc#1259365).

This update for curl fixes the following issues:

• CVE-2026-1965: bad reuse of HTTP Negotiate connection (bsc#1259362).
• CVE-2026-3783: token leak with redirect and netrc (bsc#1259363).
• CVE-2026-3784: wrong proxy connection reuse with credentials (bsc#1259364).
• CVE-2026-3805: use after free in SMB connection reuse (bsc#1259365).

This update for curl fixes the following issues:

• CVE-2026-1965: bad reuse of HTTP Negotiate connection (bsc#1259362).
• CVE-2026-3783: token leak with redirect and netrc (bsc#1259363).
• CVE-2026-3784: wrong proxy connection reuse with credentials (bsc#1259364).
• CVE-2026-3805: use after free in SMB connection reuse (bsc#1259365).

This update for curl fixes the following issues:

• CVE-2026-1965: bad reuse of HTTP Negotiate connection (bsc#1259362).
• CVE-2026-3783: token leak with redirect and netrc (bsc#1259363).
• CVE-2026-3784: wrong proxy connection reuse with credentials (bsc#1259364).
• CVE-2026-3805: use after free in SMB connection reuse (bsc#1259365).

This update for curl fixes the following issues:

Security issues fixed:

• CVE-2026-4873: connection reuse ignores TLS requirement (bsc#1262631).
• CVE-2026-5545: wrong reuse of HTTP Negotiate connection (bsc#1262632).
• CVE-2026-6253: proxy credentials leak over redirect-to proxy (bsc#1262635).
• CVE-2026-6276: stale custom cookie host causes cookie leak (bsc#1262636).
• CVE-2026-6429: netrc credential leak with reused proxy connection (bsc#1262638).

Other updates and bugfixes:

• sws: prevent "connection monitor" to say disconnect twice (bsc#1259362).

Zhicheng Chen discovered that curl could incorrectly reuse the wrong connection for Negotiate-authenticated HTTP or HTTPS requests. This could result in the use of credentials from a different connection, contrary to expectations. (CVE-2026-1965)

It was discovered that curl incorrectly leaked OAuth2 bearer tokens when following a redirect. This could result in tokens being sent to the wrong host, contrary to expectations. (CVE-2026-3783)

Muhamad Arga Reksapati discovered that curl incorrectly reused existing HTTP proxy connections even if the request used different credentials. This could result in the use of incorrect credentials, contrary to expectations. (CVE-2026-3784)

Daniel Wade discovered that curl incorrectly handled certain memory operations when doing a second SMB request to the same host. An attacker could use this issue to cause curl to crash, resulting in a denial of service, or possibly execute arbitrary code. This issue only affected Ubuntu 25.10. (CVE-2026-3805)

Yihang Zhou discovered that curl incorrectly reused .netrc file credentials when following redirects. This could result in the use of credentials for a different host, contrary to expectations. This issue only affected Ubuntu 22.04 LTS and Ubuntu 24.04 LTS. (CVE-2025-0167)

Zhicheng Chen discovered that curl could incorrectly reuse the wrong connection for Negotiate-authenticated HTTP or HTTPS requests. This could result in the use of credentials from a different connection, contrary to expectations. This issue only affected Ubuntu 20.04 LTS. (CVE-2026-1965)

It was discovered that curl incorrectly leaked OAuth2 bearer tokens when following a redirect. This could result in tokens being sent to the wrong host, contrary to expectations. This issue only affected Ubuntu 20.04 LTS. (CVE-2026-3783)

Muhamad Arga Reksapati discovered that curl incorrectly reused existing HTTP proxy connections even if the request used different credentials. This could result in the use of incorrect credentials, contrary to expectations. (CVE-2026-3784)