CVE-2026-54766
ŚrednieCVSS 5.3Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 24 - wyżej niż 24% wszystkich znanych CVE
Streszczenie
Vikunja od wersji 0.21.0 do 2.4.0 pozwala uwierzytelnionemu użytkownikowi, który może czytać projekt źródłowy, na umieszczenie jego duplikatu pod dowolnym docelowym projektem nadrzędnym. Sprawdzanie uprawnień w operacji duplikacji pomija wymóg zapisu do projektu nadrzędnego, co pozwala na wstrzyknięcie treści do hierarchii innego użytkownika lub zespołu.
Ocena ryzyka
Atakujący może wstrzyknąć nieautoryzowaną treść do projektów innych użytkowników lub zespołów, co może prowadzić do naruszenia integralności danych i zakłócenia pracy.
Rekomendacja
Zaktualizuj Vikunja do wersji 2.4.0, która zawiera poprawkę wymuszającą sprawdzenie uprawnień zapisu do projektu nadrzędnego.
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-55067Średnie
Vikunja przed wersją 2.4.0 pozwala na masowe przypisanie wartości project_view_id w żądaniu POST /api/v1/projects/{project}/views/{view}/buckets/{bucket}. Sprawdzanie uprawnień weryfikuje, że bucket należy do projektu i widoku z URL, ale nie sprawdza docelowego widoku w ciele żądania, co pozwala uwierzytelnionemu użytkownikowi przenieść bucket należący do atakującego do widoku Kanban innej dzierżawy.
- CVE-2026-55066Wysokie
Vikunja przed wersją 2.4.0 ma podatność w punkcie końcowym POST /api/v1/projects/{project}/views/{view}/buckets/{bucket}/tasks. Autoryzacja sprawdza tylko projekt, widok i kubełek z URL, ale nie sprawdza uprawnień do zadania, co pozwala uwierzytelnionemu użytkownikowi odczytać i modyfikować zadania z innych dzierżaw.
- CVE-2026-55065Wysokie
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.
- CVE-2026-55064Średnie
Vikunja od wersji 2.3.0 do 2.4.0 pozwala użytkownikowi z uprawnieniem Write (ale nie Admin) na odłączenie współdzielonego projektu podrzędnego od hierarchii nadrzędnej poprzez wysłanie parent_project_id równego 0 w POST /api/v1/projects/{project}. Sprawdzanie autoryzacji pomija wymóg Admin dla wartości zerowej, co pozwala na obejście zabezpieczenia wprowadzonego dla CVE-2026-35595.
- CVE-2026-76216Wysokie
Vikunja do wersji 2.4.0 zawiera podatność polegającą na pomyleniu typów podmiotów (principal-type confusion), gdzie podmioty LinkSharing z identyfikatorem N są traktowane jak podmioty użytkowników z users.id == N w trzech kontrolach uprawnień pozbawionych sprawdzenia typu. Atakujący z JWT link-share może usuwać ofiary z zespołów, wyliczać i usuwać boty użytkowników ofiar lub czytać listy zespołów, wykorzystując kolizje identyfikatorów w przestrzeni autoincrement.
- CVE-2026-68582Średnie
Vikunja w wersjach od 0.24.0 do 2.3.0 zawiera podatność BOLA w punkcie końcowym GET /api/v1/projects/{project}/views/{view}/tasks. Punkt końcowy ładuje widok projektu z ścieżki URL bez weryfikacji uprawnień. Posiadacz tokena linku udostępniania może odczytać rekordy kanban bucket (tytuły bucketów i pełny obiekt created_by) z dowolnego widoku w instancji. Brak autoryzacji umożliwia również wykrywanie istnienia projektów/widoków (oracle 404 vs non-404). Treści zadań pozostają ograniczone do własnego projektu udostępnienia.
- CVE-2026-68581Wysokie
Vikunja od wersji 0.22.0 do 2.3.0 nie waliduje typu principal w zarządzaniu tokenami API. Link-share JWT z pasującym ID może być użyty do zarządzania tokenami innego użytkownika.
Oryginalny opis (angielski, źródło NVD)
Vikunja is an open-source self-hosted task management platform. From 0.21.0 until 2.4.0, the project duplication operation in pkg/models/project_duplicate.go allows an authenticated user who can read a source project to place its duplicate beneath an arbitrary target parent project. ProjectDuplicate.CanCreate calls parent.CanCreate on an unhydrated Project containing only the body supplied parent_project_id instead of calling parent.CanWrite, so the target parent write-permission check is skipped. The ordinary project creation path enforces that permission, but PUT /api/v1/projects/{project}/duplicate does not, allowing attacker-owned content to be injected into another user or team project hierarchy. This issue is fixed in version 2.4.0.