Katalog podatności CVE

WSO2 Identity Server nie egzekwuje domyślnego czasu wygaśnięcia dla SMS-owych haseł jednorazowych (OTP) używanych w MFA. Nieużywane OTP pozostają ważne bezterminowo, co umożliwia atakującym przeprowadzanie ataków brute force przez wielokrotne zgadywanie kodu. Udany atak może prowadzić do obejścia MFA i przejęcia konta użytkownika.

Wtyczka Aurora Heatmap dla WordPressa do wersji 1.7.2 jest podatna na Stored Cross-Site Scripting przez parametr 'url' z powodu niewystarczającej sanityzacji wejścia i braku escape na wyjściu. Nieuwierzytelnieni atakujący mogą wstrzyknąć skrypty, które wykonają się, gdy administrator kliknie link heatmapy.

Wtyczka LatePoint dla WordPressa do wersji 5.6.9 włącznie jest podatna na niebezpieczne bezpośrednie odwołania do obiektów (IDOR). Funkcja process_step_customer() używa wyłącznie is_user_logged_in() jako zabezpieczenia przed scalaniem danych POST z istniejącym klientem LatePoint, bez sprawdzania własności. Umożliwia to uwierzytelnionym atakującym z dostępem na poziomie Subscriber lub wyższym modyfikację danych osobowych dowolnych klientów LatePoint, a przy ustawieniu contact_merge na 'phone' nadpisanie adresu e-mail ofiary i przejęcie konta przez reset hasła.

Sterownik JDBC dla PostgreSQL (pgjdbc) w wersjach od 42.7.4 do 42.7.13 dopełnia wartość krótszą niż zadeklarowana długość bajtami pozostałymi w buforze wysyłki zamiast zerami, a serwer przechowuje te bajty jako część wartości. Bajty te to wiadomości wysłane wcześniej przez sterownik na tym samym połączeniu: tekst SQL i wartości parametrów ostatnich zapytań, które w połączeniach pulowanych mogą pochodzić z innych żądań. Każda dopełniona wartość może przenosić do 8192 bajtów takiego ruchu, a przy szyfrowaniu GSS do 16320 bajtów. Dopełnianie występuje, gdy aplikacja deklaruje długość większą niż dostarczane dane, przez PreparedStatement.setObject z ByteStreamWriter, CopyIn.writeToCopy, PGCopyOutputStream.write, LargeObject.write lub Blob.setBytes. Sterownik przyjmuje te wywołania bez błędu. Atakujący, który może sprawić, że aplikacja zapisze taką wartość i odczyta ją, może zebrać wcześniejszy ruch. Aplikacje, w których deklarowane długości zawsze odpowiadają danym, nie są dotknięte. Wersje 42.7.3 i wcześniejsze dopełniają zerami.

W sterowniku pgjdbc (PostgreSQL JDBC Driver) w wersjach 42.7.11-42.7.13 brakuje wymogu uwierzytelniania, gdy właściwość requireAuth wyklucza wszystkie znane metody (np. requireAuth=!password,!md5,!gss,!sspi,!scram-sha-256,!none). Sterownik akceptuje wtedy dowolną metodę żądaną przez serwer, w tym uwierzytelnianie hasłem w postaci jawnego tekstu. Atakujący w pozycji pośredniej może przechwycić hasło bazy danych. Wersja 42.7.14 naprawia problem.

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.

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.

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.

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

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, użytkownik bez ról admin lub power może spowodować podpisanie przez Splunk Secure Gateway payloadów kontrolowanych przez atakującego. Podatność wynika z braku weryfikacji autoryzacji użytkownika do żądania podpisu.

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 spowodować denial of service na REST API endpoint w aplikacji Discover Splunk Observability Cloud. Podatność wynika z użycia nieefektywnego wyrażenia regularnego do walidacji danych wejściowych.