Katalog podatności CVE

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.

W Splunk Enterprise w wersjach poniżej 10.4.3 użytkownik z rolą posiadającą uprawnienie list_spl2_modules może wykorzystać wstrzykiwanie SQL w filtrowaniu modułów SPL2, aby uzyskać dostęp do wszystkich danych dostępnych przez REST API, w tym prywatnych definicji modułów SPL2 innych użytkowników. Podatność wynika z braku parametryzacji wartości dostarczanych przez użytkownika przed użyciem ich w zapytaniach do bazy danych.

W Splunk Enterprise w wersjach poniżej 10.4.3, 10.2.7, 10.0.10 i 9.4.15 użytkownik bez ról admin lub power może wykorzystać kontrolowany identyfikator zadania, aby uzyskać dostęp do prawie wszystkich informacji o zadaniach wyszukiwania należących do innych użytkowników, w tym tekstu zapytania, metadanych, wyników i podglądów wyników, przez REST API. Podatność wynika z niepełnej weryfikacji własności zadań przed zwróceniem informacji.

Podatność w Splunk Enterprise przed wersjami 10.4.3 i 10.2.7 pozwala nieuwierzytelnionemu użytkownikowi z dostępem sieciowym do API REST Patroni na członku klastra wyszukiwania na wykonanie poleceń systemu operacyjnego. Interfejs nie wymaga uwierzytelnienia dla krytycznych operacji konfiguracyjnych.

W Splunk Enterprise w wersjach poniżej 10.4.3, 10.2.7 i 10.0.10 użytkownik z uprawnieniem read_o11y_content może wstrzykiwać sfałszowane wpisy do dziennika aplikacji przez REST API. Podatność wynika z braku neutralizacji treści SignalFlow dostarczanych przez użytkownika przed zapisem do dziennika aplikacji w Splunk App for Splunk O11y Cloud.

W Splunk Enterprise na Linuxie w wersjach poniżej 10.4.3, 10.2.7, 10.0.10 i 9.4.15, lokalny użytkownik mogący uruchamiać polecenia jako konto użytkownika Splunk może spowodować, że aktualizacja pakietu Linuksa wykona kontrolowane przez atakującego polecenia systemowe z uprawnieniami roota. Podatność wynika z zaufania skryptu konserwacyjnego pakietu do istniejącej zawartości instalacji Splunk podczas operacji aktualizacji z uprawnieniami roota. Wymaga to, aby aktualizacja pakietu nastąpiła po modyfikacji instalacji przez lokalnego użytkownika.

W Splunk Enterprise w wersjach poniżej 10.4.3, 10.2.7, 10.0.10 i 9.4.15 oraz Splunk Secure Gateway w wersjach poniżej 3.10.11, 3.9.25 i 3.8.72, użytkownik bez ról admin lub power może uzyskać dostęp do uprzywilejowanych funkcji Splunk Secure Gateway. Dzięki temu może spowodować podpisywanie przez Splunk Secure Gateway ładunków kontrolowanych przez atakującego. Podatność wynika z braku egzekwowania wymagań autoryzacji w wielu punktach końcowych REST API.

W Splunk Enterprise w wersjach poniżej 10.4.2, 10.2.6, 10.0.10 i 9.4.15 użytkownik bez ról admin lub power może tworzyć lub edytować definicje skryptowych wyszukiwań (scripted lookups) przez surowe punkty końcowe konfiguracji. Podatność wynika z braku sprawdzania uprawnień external lookup w ścieżkach zapisu surowej konfiguracji transforms.

GitLab naprawił problem w GitLab CE/EE dotyczący wszystkich wersji od 11.7 przed 18.8.9, 18.9 przed 18.9.5 i 18.10 przed 18.10.3, który podczas importowania plików CSV mógł pozwolić uwierzytelnionemu użytkownikowi na spowodowanie odmowy usługi (DoS) dla workerów Sidekiq z powodu nieprawidłowej walidacji struktury pliku CSV.

W OpenStack Zaqar przed wersją 23.0.1 transport WebSocket nie wiąże identyfikatora projektu w kolejnych żądaniach z projektem uwierzytelnionym tokenem Keystone. Uwierzytelniony użytkownik z ważnym tokenem dla jednego projektu może podstawić UUID innego projektu, aby wyliczać, przeglądać, tworzyć lub usuwać kolejki należące do tego projektu, co prowadzi do nieautoryzowanego ujawnienia, modyfikacji lub utraty danych kolejek. Dotyczy to tylko wdrożeń używających transportu WebSocket z uwierzytelnianiem Keystone.

Brak autoryzacji w obsłudze żądań silnika Amazon Athena w wersji 3 mógł pozwolić uwierzytelnionemu użytkownikowi na odczytanie ograniczonych metadanych zapytań (identyfikatory kont AWS i tekst instrukcji SQL) z innych kont AWS. Wyniki zapytań, poświadczenia i dane Amazon S3 nie były dotknięte. AWS naprawił problem 1 września 2026 roku i potwierdził, że żadne metadane klientów nie zostały uzyskane. Nie jest wymagane działanie klienta.

Biblioteka AsyncHttpClient (AHC) w wersjach od 2.16.0 do 3.0.14 zawiera niepełną walidację atrybutów Domain w ThreadSafeCookieStore. Brakujące reguły sekcji prywatnej i domyślnych sufiksów publicznych, brak normalizacji A-label, wrażliwe na ustawienia regionalne małe litery, obsługa host-only dla sufiksów publicznych oraz brak kontroli hostów numerycznych lub IP pozwalają jednemu pochodzeniu na zapisanie ciasteczka, które później jest wysyłane do innego pochodzenia. Aplikacje współdzielące jednego klienta między domenami zaufania mogą otrzymać ciasteczka wstrzyknięte przez atakującego i być narażone na fiksację sesji. Problem naprawiono w wersji 3.0.14.

Biblioteka AsyncHttpClient (AHC) w wersjach od 2.1.0 do 3.0.14 ma domyślnie włączony magazyn ciasteczek, który zastępuje nagłówek Cookie jawnie dostarczony przez setHeader lub addHeader, gdy magazyn dostarcza jakiekolwiek ciasteczko dla danego pochodzenia. We współdzielonym kliencie zapisane ciasteczka pochodzące od jednego użytkownika mogą zastąpić ciasteczko żądania innego użytkownika, powodując wykonanie żądania w niewłaściwej sesji. To obejście wcześniejszej poprawki CVE-2024-53990, która dotyczyła ciasteczek dostarczanych przez addCookie, ale nie bezpośrednio dostarczanego nagłówka. Problem naprawiono w wersji 3.0.14.