update: curl

[dongsupark]

Name: curl
CVEs: CVE-2026-1965, CVE-2026-3783, CVE-2026-3784, CVE-2026-3805, CVE-2026-4873, CVE-2026-5545, CVE-2026-5773, CVE-2026-6253, CVE-2026-6276, CVE-2026-6429, CVE-2026-7009, CVE-2026-7168
CVSSs: 6.5, 5.3, 6.5, 7.5, 5.9, 6.5, 7.5, 5.9, 7.5, 5.3, 5.3, 5.3
Action Needed:

• CVE-2026-{1965,3783,3784,3805}: update to >= 8.19.0
• CVE-2026-{4873,5545,5773,6253,6276,6429,7009,7168}: update to >= 8.20.0

Summary:

• 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 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-3783: 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-3784: 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-3805: When doing a second SMB request to the same host again, curl would wrongly use a data pointer pointing into already freed memory.
• CVE-2026-4873: A vulnerability exists where a connection requiring TLS incorrectly reuses an existing unencrypted connection from the same connection pool. If an initial transfer is made in clear-text (via IMAP, SMTP, or POP3), a subsequent request to that same host bypasses the TLS requirement and instead transmit data unencrypted.
• CVE-2026-5545: libcurl might in some circumstances reuse the wrong connection when asked to do an authenticated HTTP(S) request after a Negotiate-authenticated one, when both use the same host. 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 criteria must 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. An application that first uses Negotiate authentication to a server with user1:password1 and then does another operation to the same server asking for any authentication method but for user2:password2 (while the previous connection is still alive) - the second request gets confused and wrongly reuses the same connection and sends the new request over that connection thinking it uses a mix of user1's and user2's credentials when it is in fact still using the connection authenticated for user1...
• CVE-2026-5773: libcurl might in some circumstances reuse the wrong connection for SMB(S) transfers. 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 criteria must be met. Due to a logical error in the code, a network transfer operation that was requested by an application could wrongfully reuse an existing SMB connection to the same server that was using a different 'share' than the new subsequent transfer should. This could in unlucky situations lead to the download of the wrong file or the upload of a file to the wrong place. When this happens, the same credentials are used and the server name is the same.
• CVE-2026-6253: curl might erroneously pass on credentials for a first proxy to a second proxy. This can happen when the following conditions are true: 1. curl is setup to use specific different proxies for different URL schemes 2. the first proxy needs credentials 3. the second proxy uses no credentials 4. while using the first proxy (using say http://), curl is asked to follow a redirect to a URL using another scheme (say https://), accessed using a second, different, proxy
• CVE-2026-6276: Using libcurl, when a custom Host: header is first set for an HTTP request and a second request is subsequently done using the same easy handle but without the custom Host: header set, the second request would use stale information and pass on cookies meant for the first host in the second request. Leak them.
• CVE-2026-6429: When asked to both use a .netrc file for credentials and to follow HTTP redirects, libcurl could leak the password used for the first host to the followed-to host under certain circumstances.
• CVE-2026-7009: When curl is told to use the Certificate Status Request TLS extension, often referred to as OCSP stapling, to verify that the server certificate is valid, it fails to detect OCSP problems and instead wrongly consider the response as fine.
• CVE-2026-7168: Successfully using libcurl to do a transfer over a specific HTTP proxy (proxyA) with Digest authentication and then changing the proxy host to a second one (proxyB) for a second transfer, reusing the same handle, makes libcurl wrongly pass on the Proxy-Authorization: header field meant for proxyA, to proxyB.

refmap.gentoo:

• CVE-2026-{1965,3783,3784,3805}: https://bugs.gentoo.org/971090
• CVE-2026-{4873,5545,5773,6253,6276,6429,7009,7168}: TBD

[dongsupark]

Added CVE-2026-{4873,5545,5773,6253,6276,6429,7009,7168}

[krnowak]

Updated curl to 8.19 in main branch.