Katalog podatności CVE

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ń.

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) 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.

Biblioteka AsyncHttpClient (AHC) w wersjach od 2.0.0 do 3.0.14 nieprawidłowo dzieli pulę połączeń dla uwierzytelniania Kerberos, SPNEGO, NTLM oraz połączeń przez autoryzowany proxy. Brakujące pola identyfikujące tożsamość mogą pozwolić na ponowne użycie gniazda uwierzytelnionego jako inna tożsamość, co prowadzi do wykonania żądania w kontekście pierwszej tożsamości i ujawnienia jej danych lub uprawnień innemu wywołującemu. Problem został naprawiony w wersji 3.0.14.

W Vault, pamięć podręczna polityk ACL pozwalała na traversing namespace, gdy nazwy polityk zawierały konstrukcje path traversal. Może to pozwolić tokenowi z odpowiednio spreparowanymi nazwami polityk na używanie uprawnień polityk zdefiniowanych w innych namespace, w tym namespace głównego. Podatność naprawiono w Vault Enterprise 2.1.2, 1.21.12, 1.20.17 i 1.19.23. Vault Community Edition nie obsługuje namespace i nie jest dotknięty.

W Vault, serwer ACME w silniku sekretów PKI nie ograniczał tożsamości certyfikatów, których wyzwania ACME nie weryfikują, przy wydawaniu certyfikatów w domyślnej polityce katalogu. Może to pozwolić klientowi ACME na uzyskanie certyfikatu zawierającego niezweryfikowane roszczenia tożsamości, co może umożliwić podszywanie się pod systemy ufające certyfikatom wydanym przez dotknięty mount PKI. Podatność naprawiono w Vault Community Edition 2.1.2 oraz Vault Enterprise 2.1.2, 1.21.12, 1.20.17 i 1.19.23.

Vault i Vault Enterprise nie spójnie weryfikowały, czy wpisy w katalogu wtyczek odnoszą się do binariów znajdujących się w skonfigurowanym katalogu wtyczek. Przy użyciu pieczęci Shamir i zewnętrznego katalogu wtyczek, uprzywilejowany operator mogący przywrócić snapshot Integrated Storage (Raft) może wykonać dowolny kod na hoście Vault. Podatność została naprawiona w Vault Community Edition 2.1.2 oraz Vault Enterprise 2.1.2, 1.21.12, 1.20.17 i 1.19.23.

W Splunk MCP Server w wersjach poniżej 1.2.1, serwer mógł wysyłać token uwierzytelniający platformy Splunk użytkownika uruchamiającego niestandardowe narzędzie API do URL skonfigurowanego dla tego narzędzia. Jeśli inny użytkownik kontroluje ten URL, może przechwycić token i użyć go do dostępu do danych i wykonywania działań jako użytkownik, który uruchomił narzędzie. Udane wykorzystanie wymaga, aby użytkownik z rolą zawierającą uprawnienie mcp_tool_execute uruchomił niestandardowe narzędzie API skonfigurowane przez innego użytkownika.

W ramach wewnętrznego przeglądu bezpieczeństwa Cisco wydało aktualizację utwardzającą, która naprawia wiele wykrytych wewnętrznie podatności. Podatności śledzone jako CVE-2026-76285 dotyczą nieprzestrzegania standardów kodowania i należą do kategorii CWE-710.

W ramach wewnętrznego przeglądu bezpieczeństwa Cisco wydało aktualizację utwardzającą, która naprawia wiele wykrytych wewnętrznie podatności. Podatności śledzone jako CVE-2026-76284 dotyczą niewłaściwej neutralizacji danych i należą do kategorii CWE-707.

W ramach ciągłego zaangażowania Cisco w proaktywne bezpieczeństwo i jakość produktów przeprowadzono kompleksowy wewnętrzny przegląd bezpieczeństwa. Przegląd ten zaowocował wydaniem wzmacniającym oprogramowanie, które naprawia wiele wewnętrznie odkrytych luk. Luki śledzone przez CVE-2026-76283 dotyczą awarii mechanizmu ochrony i są zgrupowane w kategorii CWE-693.

W ramach ciągłego zaangażowania Cisco w proaktywne bezpieczeństwo i jakość produktów przeprowadzono kompleksowy wewnętrzny przegląd bezpieczeństwa. Przegląd ten zaowocował wydaniem wzmacniającym oprogramowanie, które naprawia wiele wewnętrznie odkrytych luk. Luki śledzone przez CVE-2026-76282 dotyczą niewłaściwej kontroli zasobu przez cały jego cykl życia i są zgrupowane w kategorii CWE-664.

Cisco przeprowadziło wewnętrzny przegląd bezpieczeństwa, w wyniku którego wydano aktualizację wzmacniającą zabezpieczenia. Podatności oznaczone CVE-2026-76281 dotyczą nieprawidłowej kontroli dostępu i zostały zaklasyfikowane jako CWE-284.

W Splunk Enterprise poniżej wersji 10.4.3, 10.2.7, 10.0.10 i 9.4.15 oraz Splunk Secure Gateway poniżej 3.10.11, 3.9.25 i 3.8.72, uwierzytelniony użytkownik bez ról admin lub sc_admin może modyfikować dane alertów i urządzeń mobilnych w kolekcjach App Key Value Store, co wpływa na późniejsze przepływy pracy alertów i subskrypcji. Podatność wynika z braku ograniczeń zapisu w tych kolekcjach.

W Splunk Enterprise poniżej wersji 10.4.3, 10.2.7, 10.0.10 i 9.4.15, użytkownik z uprawnieniem run_collect może użyć polecenia collect SPL do zapisywania zdarzeń do wewnętrznych indeksów poza skonfigurowanym dla roli dostępem do indeksów. Podatność wynika z braku normalizacji białych znaków w nazwie indeksu przed zastosowaniem ograniczeń dostępu.