Описание
Security update for curl
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).
Список пакетов
Container private-registry/harbor-trivy-adapter:latest
Image pr_15_7
SUSE Linux Enterprise Module for Basesystem 15 SP7
Ссылки
- Link for SUSE-SU-2026:0903-1
- E-Mail link for SUSE-SU-2026:0903-1
- SUSE Security Ratings
- SUSE Bug 1259362
- SUSE Bug 1259363
- SUSE Bug 1259364
- SUSE Bug 1259365
- SUSE CVE CVE-2026-1965 page
- SUSE CVE CVE-2026-3783 page
- SUSE CVE CVE-2026-3784 page
- SUSE CVE CVE-2026-3805 page
Описание
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
- SUSE Bug 1259362
Описание
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
- SUSE Bug 1259363
Описание
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
- SUSE Bug 1259364
Описание
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-3805
- SUSE Bug 1259365