Katalog podatności CVE

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.

W Splunk Enterprise poniżej wersji 10.4.3, 10.2.7 i 10.0.10, użytkownik z uprawnieniem edit_spl2_module_permissions może użyć REST API do uzyskania informacji o uprawnieniach modułów SPL2, których nie ma prawa przeglądać. Podatność wynika z braku weryfikacji, czy użytkownik może czytać aplikację przed zwróceniem uprawnień modułu.

W Splunk Enterprise poniżej wersji 10.4.3, 10.2.7, 10.0.10 i 9.4.15, użytkownik z uprawnieniem edit_user może utworzyć nazwę użytkownika kończącą się kropką. Walidacja nazwy nie odrzuca końcowej kropki, co powoduje, że różne nazwy mogą współdzielić dane konfiguracyjne, a operacje zarządzania użytkownikami mogą dotyczyć niewłaściwego konta lub kończyć się niepowodzeniem.

W Splunk Enterprise poniżej wersji 10.4.3, 10.2.7 i 10.0.10, użytkownik z niskimi uprawnieniami (bez ról admin lub power) może pobrać oryginalny kod źródłowy aplikacji Discover Splunk Observability Cloud przez Splunk Web. Podatność wynika z osadzonych source map w produkcji, które zawierają oryginalny kod źródłowy.

W Splunk Enterprise poniżej wersji 10.4.3, 10.2.7, 10.0.10 i 9.4.15, użytkownik bez ról admin lub power może uzyskać dostęp do tekstu zapytań i metadanych zadań innych użytkowników przez REST API. Podatność wynika z niepełnego egzekwowania autoryzacji per użytkownik przy wyświetlaniu listy zadań.

W Splunk Enterprise poniżej wersji 10.4.3, 10.2.7 i 10.0.10, użytkownik z uprawnieniem read_o11y_content może przekierować wychodzące żądanie z aplikacji Splunk App for Splunk Observability Cloud przez REST API na kontrolowany przez atakującego host i ujawnić skonfigurowany token API Observability Cloud. Podatność wynika z niepełnej walidacji celu wychodzącego żądania.

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 dodania treści kontrolowanej przez atakującego do komunikatów na poziomie systemowym. Podatność wynika z braku walidacji nazwy indeksu przed przetworzeniem wartości.