Описание
Security update for curl
This update for curl fixes the following issues:
- 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).
Список пакетов
openSUSE Leap 16.0
Ссылки
- SUSE Security Ratings
- SUSE Bug 1262631
- SUSE Bug 1262632
- SUSE Bug 1262635
- SUSE Bug 1262636
- SUSE Bug 1262638
- SUSE CVE CVE-2026-4873 page
- SUSE CVE CVE-2026-5545 page
- SUSE CVE CVE-2026-6253 page
- SUSE CVE CVE-2026-6276 page
- SUSE CVE CVE-2026-6429 page
Описание
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-4873
- SUSE Bug 1262631
Описание
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-5545
- SUSE Bug 1262632
- SUSE Bug 1268407
Описание
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-6253
- SUSE Bug 1262635
- SUSE Bug 1268299
Описание
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-6276
- SUSE Bug 1262636
Описание
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-6429
- SUSE Bug 1262638