CVE-2026-1965
ŚrednieCVSS 6.5Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 18 - wyżej niż 18% wszystkich znanych CVE
Streszczenie
W bibliotece libcurl występuje błąd logiczny w mechanizmie ponownego wykorzystywania połączeń. W pewnych okolicznościach żądanie HTTP lub HTTPS z uwierzytelnianiem Negotiate może błędnie użyć istniejącego połączenia uwierzytelnionego innymi danymi logowania. W efekcie drugie żądanie z innymi poświadczeniami może zostać wysłane przez połączenie uwierzytelnione dla pierwszego użytkownika.
Ocena ryzyka
Aplikacja może wysłać żądanie z poświadczeniami użytkownika2 przez połączenie uwierzytelnione jako użytkownik1, co prowadzi do nieautoryzowanego dostępu do zasobów lub działań w kontekście niewłaściwego konta. Stanowi to ryzyko naruszenia poufności i integralności danych oraz obejścia kontroli dostępu.
Rekomendacja
Zaktualizuj libcurl do wersji zawierającej poprawkę tego błędu. Jeśli aktualizacja nie jest możliwa, wyłącz ponowne wykorzystywanie połączeń, ustawiając opcje CURLOPT_FRESH_CONNECT, CURLOPT_MAXCONNECTS lub CURLMOPT_MAX_HOST_CONNECTIONS (przy korzystaniu z API curl_multi).
Inne podatności w libcurl
Zobacz wszystkie- CVE-2022-27782Wysokie
W bibliotece libcurl występuje problem z ponownym używaniem wcześniej utworzonych połączeń, nawet gdy zmieniono opcje związane z TLS lub SSH, które powinny zabraniać ponownego użycia. Niektóre ustawienia TLS i SSH nie były uwzględnione w sprawdzaniu zgodności konfiguracji, co ułatwiało dopasowanie.
- CVE-2022-27781Wysokie
libcurl oferuje opcję `CURLOPT_CERTINFO`, która pozwala aplikacjom na żądanie szczegółów dotyczących łańcucha certyfikatów serwera. Z powodu błędnej funkcji, złośliwy serwer może spowodować, że libcurl zbudowany z NSS utknie w nieskończonej pętli podczas próby pobrania tych informacji.
- CVE-2021-22926Wysokie
Aplikacje korzystające z libcurl mogą żądać użycia konkretnego certyfikatu klienta podczas transferu. W przypadku, gdy libcurl jest zbudowany z użyciem natywnej biblioteki TLS macOS Secure Transport, złośliwy użytkownik może podmienić certyfikat, co prowadzi do wysłania niewłaściwego certyfikatu klienta w procesie handshake TLS.
- CVE-2017-1000254Wysokie
libcurl może odczytywać dane poza przydzielonym buforem pamięci podczas korzystania z FTP. Błąd w analizatorze ciągów dla nazwy katalogu może prowadzić do braku dodania bajtu NUL na końcu bufora, co skutkuje możliwością odczytu danych spoza przydzielonego obszaru pamięci.
- CVE-2016-5421Wysokie
Podatność typu use-after-free w libcurl przed wersją 7.50.1 pozwala atakującym na kontrolowanie, która konekcja jest używana, lub potencjalnie na wywołanie innych nieokreślonych skutków za pomocą nieznanych wektorów.
- CVE-2016-0755Wysokie
Funkcja ConnectionExists w lib/url.c w libcurl przed wersją 7.47.0 nieprawidłowo ponownie wykorzystuje połączenia proxy uwierzytelnione za pomocą NTLM, co może umożliwić zdalnym atakującym uwierzytelnienie jako inni użytkownicy poprzez odpowiednie żądanie.
- CVE-2024-2398Średnie
Podatność w bibliotece libcurl powoduje wyciek pamięci podczas obsługi push HTTP/2. Gdy aplikacja zezwala na push serwera, a liczba nagłówków przekracza limit 1000, libcurl przerywa push, ale nie zwalnia poprzednio zaalokowanych nagłówków.
- CVE-2024-6874Średnie
Funkcja curl_url_get() w libcurl oferuje konwersje punycode do i z IDN. Przy konwersji nazwy o dokładnie 256 bajtach, libcurl czyta poza buforem na stosie, gdy używany jest backend IDN macidn.
- CVE-2025-4947Średnie
libcurl przypadkowo pomija weryfikację certyfikatu dla połączeń QUIC, gdy łączy się z hostem podanym jako adres IP w URL. W związku z tym nie wykrywa oszustów ani ataków man-in-the-middle.
- CVE-2024-6197Wysokie
Parser ASN1 w libcurl zawiera funkcję utf8asn1str() używaną do parsowania łańcucha UTF-8 ASN.1. Może on wykryć nieprawidłowe pole i zwrócić błąd. Niestety, podczas tego procesu wywołuje również free() na 4-bajtowym buforze lokalnym na stosie. Większość nowoczesnych implementacji malloc wykrywa ten błąd i natychmiast przerywa działanie.
Oryginalny opis (angielski, źródło NVD)
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).
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS