CVE-2026-92920
ŚrednieCVSS 5.4Streszczenie
Aplikacja admin3 w wersjach do 3.0.0 nie unieważnia istniejących sesji przy wyłączaniu konta użytkownika, co pozwala atakującym zachować uwierzytelniony dostęp z pierwotnymi uprawnieniami. Tokeny bearer wydane przed wyłączeniem konta nadal działają, ponieważ AuthInterceptor nigdy nie sprawdza ponownie statusu zablokowania użytkownika, a wygaśnięcie sesji resetuje się przy każdym żądaniu.
Ocena ryzyka
Byli lub zablokowani użytkownicy mogą nadal korzystać z systemu z pełnymi uprawnieniami, co może prowadzić do nieautoryzowanych działań i naruszenia bezpieczeństwa danych.
Rekomendacja
Należy wdrożyć natychmiastowe unieważnianie sesji i tokenów przy wyłączaniu konta oraz ponowną weryfikację statusu zablokowania użytkownika w AuthInterceptor przy każdym żądaniu.
Inne podatności w admin3
Zobacz wszystkie- CVE-2026-92921Średnie
Aplikacja admin3 w wersjach do 3.0.0 przechowuje hasła kont przy użyciu pojedynczej rundy MD5, używając jedynie nazwy użytkownika jako soli i bez funkcji wyprowadzania klucza. Atakujący mający dostęp do bazy danych może odzyskać hasła w postaci jawnej poprzez ataki słownikowe lub brute-force offline.
- CVE-2026-92919Wysokie
Aplikacja admin3 w wersjach do 3.0.0 nie sanityzuje nazw plików dostarczanych przez klienta w module obsługi przesyłania, co pozwala uwierzytelnionym użytkownikom zapisywać pliki poza katalogiem głównym w środowiskach Windows. Atakujący mogą użyć segmentów ścieżki z kropkami, aby wyjść poza skonfigurowany katalog i nadpisać dowolne pliki dostępne dla procesu serwera.
- CVE-2026-92918Wysokie
Aplikacja admin3 w wersjach do 3.0.0 przechowuje tokeny sesji użytkowników w treści zdarzenia dziennika audytu podczas publikowania zdarzeń domenowych UserLoggedIn. Atakujący z uprawnieniem log:view może odczytać odpowiedź JSON z punktu końcowego GET /logs, aby pozyskać tokeny sesji i użyć ich jako poświadczeń bearer do pełnego dostępu do konta użytkownika.
Oryginalny opis (angielski, źródło NVD)
admin3 through 3.0.0 fails to invalidate existing sessions when disabling a user account, allowing attackers to retain authenticated access with original permissions. Attackers can continue using bearer tokens issued before account disablement to authenticate requests, as the AuthInterceptor never re-validates the user's locked status and session expiry resets on each request.