CVE-2023-41041
NiskieCVSS 2.6Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 33 - wyżej niż 33% wszystkich znanych CVE
Streszczenie
W platformie Graylog, w przypadku klastrów wielowęzłowych, sesja użytkownika może być nadal używana do żądań API po wylogowaniu, aż do osiągnięcia pierwotnego czasu wygaśnięcia. Każdy węzeł utrzymuje lokalną pamięć podręczną sesji użytkowników, co prowadzi do sytuacji, w której inne węzły mogą nadal akceptować sesję po jej usunięciu z lokalnej pamięci podręcznej.
Ocena ryzyka
Organizacja może być narażona na ryzyko nieautoryzowanego dostępu do API, nawet po wylogowaniu użytkownika, co może prowadzić do potencjalnych naruszeń bezpieczeństwa danych.
Rekomendacja
Zaleca się aktualizację do wersji 5.0.9 lub 5.1.3, aby usunąć tę podatność. Dodatkowo, warto rozważyć implementację dodatkowych środków zabezpieczających, aby ograniczyć ryzyko związane z wykorzystaniem sesji po wylogowaniu.
Inne podatności w Graylog
Zobacz wszystkie- CVE-2026-69190Średnie
W platformie Graylog API aktualizacji widoków dla zapisanych wyszukiwań i pulpitów pozwala użytkownikowi z uprawnieniem edycji, ale bez własności encji, dołączyć shareRequest przyznający uprawnienia właściciela dowolnemu kontu. Wybrane konto może następnie usunąć zapisane wyszukiwanie lub pulpit albo odebrać dostęp pierwotnemu właścicielowi. Problem dotyczy wersji od 6.3.0 do 6.3.14, 7.0.9 i 7.1.4.
- CVE-2026-92789Średnie
Graylog do wersji 7.1.4 włącznie waliduje wychodzące adresy URL względem listy dozwolonych przed wykonaniem żądań, ale nie powtarza walidacji po przekierowaniach HTTP. Atakujący z uprawnieniami do tabel wyszukiwań lub powiadomień o zdarzeniach może spreparować dozwolone endpointy przekierowujące do usług wewnętrznych, umożliwiając serwerowi pobranie i zwrócenie wewnętrznych odpowiedzi.
- CVE-2026-55867Średnie
Graylog w wersjach od 6.2.0 do 6.3.12, 7.0.7 i 7.1.2 ma podatność w endpointcie DELETE /users/{userId}/tokens/{idOrToken}, gdzie sprawdzane są uprawnienia USERS_TOKENREMOVE dla parametru userId kontrolowanego przez atakującego, zanim zostanie rozwiązany token wybrany przez idOrToken. Uwierzytelniony użytkownik może podać autoryzowany userId, podczas gdy loadById() lub load() rozwiązuje token należący do innego użytkownika, w tym konta usługowego lub administratora, po czym destroy() usuwa ten token bez sprawdzenia AccessToken.getUserName(). Problem nie ujawnia zawartości tokena, ale nieautoryzowane usunięcie ma wpływ na integralność i może zakłócić integracje oparte na tokenach.
- CVE-2026-55841Wysokie
Podatność w Graylog Server przed wersjami 6.3.12, 7.0.7 i 7.1.2 oraz Graylog Forwarder przed wersją 7.3. Parser syslog FortiGate nieprawidłowo obsługuje pola wewnątrz wartości cytowanych, co pozwala nieuwierzytelnionemu nadawcy na manipulację polami logów bezpieczeństwa lub unikanie logowania, ukrywając złośliwą aktywność.
- CVE-2026-55425Średnie
Graylog od wersji 7.1.0 do 7.1.4 oraz 7.2.0-alpha.2 pozwala uwierzytelnionemu użytkownikowi na żądanie złożonych pól wyświetlania w endpointcie tytułów encji System Catalog bez weryfikacji, czy każde wybrane pole jest czytelne. Użytkownik może pobrać chronione wartości, w tym hash hasła z czytelnego rekordu użytkownika; zwykli użytkownicy są ograniczeni do własnych rekordów, a administratorzy mogą pobrać hashe wszystkich użytkowników.
- CVE-2023-41045Niskie
Graylog, platforma do zarządzania logami, wykorzystuje jeden port źródłowy do zapytań DNS, co narusza zalecane praktyki bezpieczeństwa. To może umożliwić ataki typu DNS cache poisoning, gdzie zewnętrzny atakujący może wstrzykiwać fałszywe odpowiedzi DNS do pamięci podręcznej Grayloga.
- CVE-2023-41044Niskie
W Graylog występuje częściowa podatność na przejście ścieżki w funkcji `Support Bundle`, która pozwala atakującemu z ważnymi poświadczeniami roli Admin na pobieranie lub usuwanie plików w sąsiednich katalogach. Problem wynika z niewłaściwej walidacji danych wejściowych w zasobie API HTTP.
Oryginalny opis (angielski, źródło NVD)
Graylog is a free and open log management platform. In a multi-node Graylog cluster, after a user has explicitly logged out, a user session may still be used for API requests until it has reached its original expiry time. Each node maintains an in-memory cache of user sessions. Upon a cache-miss, the session is loaded from the database. After that, the node operates solely on the cached session. Modifications to sessions will update the cached version as well as the session persisted in the database. However, each node maintains their isolated version of the session. When the user logs out, the session is removed from the node-local cache and deleted from the database. The other nodes will however still use the cached session. These nodes will only fail to accept the session id if they intent to update the session in the database. They will then notice that the session is gone. This is true for most API requests originating from user interaction with the Graylog UI because these will lead to an update of the session's "last access" timestamp. If the session update is however prevented by setting the `X-Graylog-No-Session-Extension:true` header in the request, the node will consider the (cached) session valid until the session is expired according to its timeout setting. No session identifiers are leaked. After a user has logged out, the UI shows the login screen again, which gives the user the impression that their session is not valid anymore. However, if the session becomes compromised later, it can still be used to perform API requests against the Graylog cluster. The time frame for this is limited to the configured session lifetime, starting from the time when the user logged out. This issue has been addressed in versions 5.0.9 and 5.1.3. Users are advised to upgrade.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS