CVE-2026-12593
WysokieCVSS 8.7Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 20 - wyżej niż 20% wszystkich znanych CVE
Streszczenie
Wewnętrzny i nieudokumentowany endpoint API Dashboardu (POST /api/users/~/{user}/tokens) nie sprawdzał wystarczających uprawnień przy tworzeniu tokena API dla innego użytkownika. Atakujący znający login uprzywilejowanego użytkownika wewnętrznego i uwierzytelniony przez OAuth/OIDC mógł sfałszować żądanie utworzenia tokena w jego imieniu.
Ocena ryzyka
W najgorszym przypadku atakujący mógł uzyskać uprawnienia administratora Dashboardu i wykonać wszystkie akcje administracyjne. W połączeniu z inną słabością mogło to prowadzić do wykonania kodu na hoście z uprawnieniami użytkownika systemowego uruchamiającego Dashboard.
Rekomendacja
Należy natychmiast zaktualizować Dashboard do wersji, w której poprawiono sprawdzanie uprawnień dla endpointu tworzenia tokenów API. Dodatkowo ogranicz dostęp do Dashboardu tylko dla zaufanych użytkowników OAuth/OIDC.
Inne podatności w Dashboard
Zobacz wszystkie- CVE-2026-42127Wysokie
Publiczny endpoint zapytań dashboardu nie ogranicza rozmiaru treści żądania przed przetworzeniem, co pozwala nieuwierzytelnionym atakującym na wywołanie nadmiernej alokacji pamięci poprzez wysyłanie dowolnie dużych ładunków JSON. Może to prowadzić do odmowy usługi przez wyczerpanie pamięci.
- CVE-2026-33377Wysokie
Edytor może nadpisać pulpit nawigacyjny, który nie jest jego własnością, aby uzyskać uprawnienia administratora do tego konkretnego pulpitu. Użytkownik musi mieć dostęp do zapisu, aby podnieść swoje uprawnienia.
Oryginalny opis (angielski, źródło NVD)
The implementation of an internal and undocumented Dashboard API endpoint (POST /api/users/~/{user}/tokens) forgot to ensure an HTTP request for creating an API Token for another user had sufficient permission to do so. Precondition for successful exploitation was a preexisting internal user (with more privileges than the attacker), the attacker knowing its login name and the attacker being able to authenticate to the Dashboard via OAuth/OIDC. The attacker would then have had to forge a token creation API request on behalf of the other user and could have authenticated and finalized the token creation with their own OAuth/OIDC credentials. In the worst case, this would mean an attacker could have become Dashboard Administrator and been able to perform all administrative actions if the preexisting internal user had administrative privileges. In combination with a separate weakness, this could have further led to code execution on the host system running the Dashboard with the privileges of the OS-User running the Dashboard server.

