CVE-2026-102740

Podatność w bibliotece AsyncHttpClient (AHC) przed wersjami 3.0.13 i 2.16.1 umożliwia powtórne wysłanie żądania do innego hosta, ale pozostawia oryginalny cel i kontekst proxy. Może to spowodować wysłanie ścieżki, nagłówka Host, poświadczeń lub zwykłego tekstu do miejsca docelowego replikacji.

Biblioteka AsyncHttpClient (AHC) w wersjach od 2.1.0 do 3.0.14 nie zachowuje informacji o tym, czy odpowiedź Set-Cookie została odebrana przez bezpieczne połączenie. Domyślny ThreadSafeCookieStore akceptuje ciasteczka Secure przesyłane plaintextem i pozwala niezabezpieczonym ciasteczkom nadpisywać lub usuwać istniejące ciasteczka Secure. Atakujący kontrolujący odpowiedź same-site w plaintext może sadzić, zastępować lub usuwać stan ciasteczek wysyłany później do origin HTTPS.

W bibliotece AsyncHttpClient (AHC) przed wersjami 3.0.12 i 2.16.1, żądanie WebSocket przez proxy (ws) jest przekazywane przez CONNECT, ale NettyRequestFactory.newNettyRequest i requestUri decydują o dodaniu uwierzytelnienia proxy i formy absolutnej tylko na podstawie tego, czy URI jest bezpieczny. Ponieważ ws nie jest oznaczony jako bezpieczny, tunelowane uaktualnienie WebSocket wysyłane do origin zawiera wartość Proxy-Authorization proxy. Poświadczenia Basic są bezpośrednio odzyskiwalne, a odpowiedzi Digest mogą być odtwarzane lub łamane offline. Problem naprawiono w wersjach 3.0.12 i 2.16.1.

Biblioteka AsyncHttpClient (AHC) przed wersjami 3.0.12 i 2.16.1 ma podatność w WebSocketHandler.upgrade, która przerywa uzgadnianie (handshake) przy braku lub nieprawidłowej wartości Sec-WebSocket-Accept, ale kontynuuje instalację pipeline'u i dostarczenie onOpen. Ramki połączone z nieprawidłową odpowiedzią 101 mogą być zdekodowane i dostarczone od peera, który nie udowodnił uzgadniania, mimo że przyszłość żądania kończy się niepowodzeniem i kanał jest zamykany. Problem naprawiono w wersjach 3.0.12 i 2.16.1.

Biblioteka AsyncHttpClient (AHC) przed wersjami 3.0.12 i 2.16.1 generuje losowy identyfikator cnonce dla uwierzytelniania Digest przy użyciu ThreadLocalRandom zamiast kryptograficznie bezpiecznego źródła losowości. To sprawia, że mechanizm uwierzytelniania jest podatny na ataki typu wybór tekstu jawnego i prekomputację poświadczeń.

Biblioteka AsyncHttpClient (AHC) umożliwia aplikacjom Java łatwe wykonywanie żądań HTTP i asynchroniczne przetwarzanie odpowiedzi. Przed wersjami 3.0.13 i 2.16.1 klucz puli połączeń HTTP/1.1 nie uwzględnia uwierzytelnionego podmiotu dla uwierzytelniania NTLM i Negotiate zorientowanego na połączenie. Połączony gniazdo uwierzytelnione dla jednego żądania może być ponownie użyte przez żądanie z innym podmiotem, a serwer wykonuje to późniejsze żądanie jako pierwszą tożsamość. Basic i Digest nie są dotknięte, ponieważ uwierzytelniają każde żądanie. Problem naprawiono w wersjach 3.0.13 i 2.16.1.

W bibliotece AsyncHttpClient (AHC) przed wersjami 3.0.13 i 2.16.1, ThreadSafeCookieStore waliduje atrybuty Domain za pomocą dopasowania domen, ale nie odrzuca publicznych sufiksów. Host pod sufiksem takim jak co.uk może ustawić cookie dla tego sufiksu, po czym współdzielony magazyn cookie wysyła je do niepowiązanych hostów pod tym sufiksem. Może to wstrzykiwać lub nadpisywać wartości cookie istotne dla sesji między originami. Problem naprawiono w wersjach 3.0.13 i 2.16.1.

Biblioteka AsyncHttpClient (AHC) umożliwia aplikacjom Java łatwe wykonywanie żądań HTTP i asynchroniczne przetwarzanie odpowiedzi. W wersji 3.0.12, peer oferujący tylko Digest qop=auth-int powoduje pominięcie weryfikacji wzajemnego uwierzytelniania. AuthenticatorUtils.computeExpectedRspAuth nie zwraca oczekiwanej wartości dla auth-int, a Interceptors traktuje ten wynik jako niezweryfikowany, ale niekrytyczny, więc odpowiedź z nieprawidłową wartością rspauth jest akceptowana. Peer, który nie zna wspólnego sekretu, może zostać zaakceptowany jako uwierzytelniony serwer. Problem naprawiono w wersji 3.0.13.

Biblioteka AsyncHttpClient (AHC) umożliwia aplikacjom Java łatwe wykonywanie żądań HTTP i asynchroniczne przetwarzanie odpowiedzi. Przed wersjami 3.0.12 (na 3.x) i 2.16.1 (na 2.x), klient wnioskuje, że tunel proxy HTTP istnieje na podstawie ostatniej metody żądania, a nie wyniku CONNECT. Po odrzuceniu CONNECT przez proxy, handlery przekierowań lub uwierzytelniania mogą zapisać żądanie pochodzenia i jego poświadczenia Authorization na nadal jawnym połączeniu proxy. Podstawowe poświadczenia mogą być odzyskane bezpośrednio, a odpowiedzi NTLM mogą być złamane lub przekazane dalej. Problem naprawiono w wersjach 3.0.12 i 2.16.1.

Biblioteka AsyncHttpClient (AHC) umożliwia aplikacjom Java łatwe wykonywanie żądań HTTP i asynchroniczne przetwarzanie odpowiedzi. Przed wersjami 3.0.13 i 2.16.1, Realm.Builder traktuje wyzwanie Digest, które nie daje użytecznego nonce, jako wyzwanie Basic. Złośliwe źródło lub proxy może oznaczyć wyzwanie jako Digest, pomijając lub opróżniając nonce, co powoduje, że klient wysyła nazwę użytkownika i hasło przy użyciu odwracalnego uwierzytelniania Basic. Dotyczy to zarówno parserów wyzwań źródła, jak i proxy. Problem naprawiono w wersjach 3.0.13 i 2.16.1.