CVE-2026-5545
ŚrednieCVSS 6.5Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 35 - wyżej niż 35% wszystkich znanych CVE
Streszczenie
libcurl może w pewnych okolicznościach ponownie użyć niewłaściwego połączenia przy żądaniu uwierzytelnionego transferu HTTP(S) po transferze uwierzytelnionym przez Negotiate, gdy oba używają tego samego hosta. Błąd logiczny w kodzie powoduje, że żądanie może błędnie ponownie użyć istniejącego połączenia uwierzytelnionego innymi poświadczeniami.
Ocena ryzyka
Żądanie może zostać wysłane z poświadczeniami innego użytkownika, co prowadzi do pomieszania tożsamości i potencjalnego nieautoryzowanego dostępu. Może to naruszyć izolację sesji i poufność danych.
Rekomendacja
Zaktualizuj libcurl do wersji, w której pula połączeń prawidłowo rozróżnia poświadczenia przy ponownym użyciu. Unikaj mieszania metod uwierzytelniania na tym samym hoście w ramach jednego uchwytu.
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 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...
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS

