CVE-2026-55065
WysokieCVSS 8.1Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 28 - wyżej niż 28% wszystkich znanych CVE
Streszczenie
Vikunja od wersji 0.24.6 do 2.4.0 ma podatność w punkcie końcowym DELETE /api/v1/projects/:project/views/:view. Uwierzytelniony użytkownik może podać identyfikator widoku z innego projektu, a autoryzacja sprawdza tylko identyfikator projektu, co pozwala na usunięcie przypisań Kanban i kolejności zadań w innych dzierżawach.
Ocena ryzyka
Atakujący może zniszczyć dane Kanban i kolejność zadań w innych dzierżawach, co narusza integralność danych i może zakłócić pracę zespołów.
Rekomendacja
Zaktualizuj Vikunja do wersji 2.4.0, która zawiera poprawkę.
Inne podatności w Vikunja
Zobacz wszystkie- CVE-2026-56765Krytyczne
Podatność w Vikunja przed wersją 2.2.1 umożliwia nieautoryzowany dostęp do skrótów udostępnień oraz pobieranie i usuwanie załączników plików w całej instancji. Błąd autoryzacji w endpointach LinkSharing.ReadAll i GetTaskAttachment pozwala na eskalację uprawnień do poziomu administratora.
- CVE-2026-62376Wysokie
Vikunja w wersjach przed 2.4.0 przechowuje tokeny resetowania hasła, potwierdzenia e-mail i usunięcia konta w tabeli user_tokens w postaci jawnej. Atakujący z dostępem do odczytu bazy danych może natychmiast użyć oczekujących tokenów do przejęcia kont użytkowników bez znajomości haseł. Problem naprawiono w wersji 2.4.0.
- CVE-2026-62367Wysokie
Vikunja w wersjach 1.0.0–2.3.0, gdy administrator włączy opcję emailfallback dla dostawcy OpenID Connect, łączy logowanie SSO z istniejącym kontem lokalnym wyłącznie na podstawie oświadczenia email od IdP, bez weryfikacji email_verified ani wymogu hasła. Atakujący z tokenem zawierającym e-mail ofiary może zalogować się jako ona bez jej zgody. Problem naprawiono w wersji 2.4.0.
- CVE-2026-57458Wysokie
Vikunja w wersji 2.3.0 pozwala tokenowi API ograniczonemu do uprawnienia oauth.authorize wywołać POST /api/v1/oauth/authorize, uzyskać kod autoryzacyjny OAuth i wymienić go na zwykły token JWT oraz refresh token. Uzyskane poświadczenia nie są ograniczone uprawnieniami oryginalnego tokenu API, co daje dostęp do tras spoza zadeklarowanego zakresu. Problem naprawiono w wersji 2.4.0.
- CVE-2026-91985Wysokie
Vikunja przed wersją 2.6.0 nie ogranicza prawidłowo dostępu do pola hasha udostępniania linku w endpointach odczytu pojedynczego udostępnienia, co pozwala członkom z uprawnieniami tylko do odczytu na uzyskanie sekretnego poświadczenia udostępnienia. Atakujący mogą wymienić ujawniony hash na JWT linku udostępniania na poziomie uprawnień udostępnienia, aby eskalować uprawnienia i wykonywać nieautoryzowane operacje zapisu lub administracyjne.
- CVE-2026-91984Średnie
Vikunja w wersjach przed 2.6.0 nie weryfikuje, czy podany przez użytkownika project_view_id w żądaniach pozycji zadań należy do projektu danego zadania. Uwierzytelniony atakujący może wstawiać wiersze pozycji zadań do widoków projektów innych najemców (tenantów) poprzez endpointy POST lub PUT.
- CVE-2026-91983Średnie
Vikunja w wersjach przed 2.6.0 zawiera podatność obejścia zakresu tokena API w endpointach odczytu zadań, gdzie autoryzacja nie sprawdza parametrów zapytania. Atakujący z ograniczonym zakresem tokena może użyć parametru expand, aby uzyskać dostęp do danych takich jak komentarze, reakcje i wpisy czasu bez weryfikacji uprawnień.
- CVE-2026-91982Średnie
Vikunja w wersjach przed 2.6.0 nadal ujawnia surowy współdzielony sekret TOTP po rejestracji poprzez endpointy GET /api/v1/user/settings/totp oraz /api/v1/user/settings/totp/qrcode bez ponownej autoryzacji. Atakujący z ważnym tokenem dostępu może odczytać sekret, zaimportować go do własnego authenticatora i generować ważne kody bezterminowo.
- CVE-2026-91981Średnie
Vikunja w wersjach przed 2.6.0 nieprawidłowo waliduje tokeny udostępniania linków w endpointach wyszukiwania użytkowników API v2. Atakujący z linkiem udostępniania tylko do odczytu może wyliczać użytkowników projektu poprzez endpoint projektów oraz potwierdzać istnienie dowolnych nazw użytkowników poprzez globalny endpoint wyszukiwania.
- CVE-2026-91980Średnie
Vikunja w wersjach przed 2.6.0 nie weryfikuje dostępu do zespołów podczas przypisywania zespołów do projektów, co pozwala uwierzytelnionym użytkownikom wyliczać wszystkie zespoły i ich członków. Atakujący może przypisać dowolne identyfikatory zespołów poprzez endpoint zespołów projektu, aby uzyskać pełne listy członków, w tym nazwiska i flagi administratora.
Oryginalny opis (angielski, źródło NVD)
Vikunja is an open-source self-hosted task management platform. From 0.24.6 until 2.4.0, DELETE /api/v1/projects/:project/views/:view permits an authenticated user to supply a view identifier from another project while authorizing only against an attacker-controlled project identifier. ProjectView.CanDelete in pkg/models/project_view_permissions.go does not establish that the view belongs to the path project, and ProjectView.Delete in pkg/models/project_view.go continues after the scoped project_views delete affects no rows. Its subsequent deletes select task_buckets and task_positions only by project_view_id, allowing cross-tenant destruction of Kanban assignments and ordering while leaving the victim view and tasks intact. This issue is fixed in version 2.4.0.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS

