Podatności Vikunja

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.

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.

Vikunja w wersjach przed 2.6.0 nie ogranicza rozpakowywania archiwów podczas importu danych, co pozwala uwierzytelnionym użytkownikom wywołać odmowę usługi. Atakujący może przesłać wysoce skompresowane pliki, które rozpakowują się do dziesiątek gigabajtów w pamięci i na dysku, wyczerpując zasoby serwera i powodując awarię instancji.

Vikunja przed wersją 2.6.0 zawiera podatność na obejście uwierzytelniania w endpointach CalDAV BasicAuth, które nie mają ochrony przed limitowaniem żądań. Zdalni nieuwierzytelnieni atakujący mogą wysyłać nieograniczone żądania zgadywania poświadczeń do /dav, /.well-known i /feeds, aby ominąć zabezpieczenia anty-brute-force i skompromitować konta chronione tylko hasłem.

Vikunja przed wersją 2.6.0 nie stosuje limitowania żądań do publicznych endpointów autoryzacji /api/v2, w tym login, register, password-reset i OAuth token. Zdalni nieuwierzytelnieni atakujący mogą przeprowadzać nieograniczone zgadywanie poświadczeń, enumerację kont i ataki typu password-reset flooding bez ograniczeń.

Vikunja w wersjach przed 2.6.0 nie stosuje limitów dekodowania pikseli w endpointach przesyłania awatarów i teł projektów, co pozwala uwierzytelnionym użytkownikom przesyłać spreparowane obrazy dekodujące się do nadmiernej liczby pikseli. Atakujący może przesyłać małe obrazy o ekstremalnych proporcjach, które zużywają znaczną ilość CPU i pamięci podczas przetwarzania, powodując odmowę usługi.

Vikunja w wersjach przed 2.6.0 zawiera podatność na wyczerpanie zasobów w migratorze Planka, który nie egzekwuje zagregowanych budżetów pamięci podczas zadań migracji. Uwierzytelnieni atakujący mogą przesyłać żądania migracji wskazujące na serwery kontrolowane przez atakującego, reklamujące liczne załączniki o zgodnym rozmiarze, wyczerpując pamięć procesu roboczego i powodując odmowę usługi dla wszystkich użytkowników.

Vikunja w wersjach przed 2.6.0 zawiera podatność na wyczerpanie zasobów w endpoincie POST /api/v2/migration/csv/migrate, który nie ogranicza liczby przetwarzanych wierszy. Uwierzytelnieni atakujący mogą przesyłać wieloczęściowe pliki CSV z milionami małych rekordów, aby wyczerpać pamięć procesu i zatrzymać usługę API.

Vikunja w wersjach przed 2.6.0 zawiera podatność na wyczerpanie zasobów w endpoincie filtrowania zadań, który akceptuje głęboko zagnieżdżone wyrażenia filtrów bez limitów głębokości rekurencji. Uwierzytelnieni atakujący mogą podać tysiące zagnieżdżonych nawiasów w parametrze zapytania filtra, aby wyczerpać pamięć i zatrzymać proces API.

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.

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.

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.

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.

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.

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.

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.

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.

W Vikunja przed wersją 2.3.0 egzekwowanie zakresu tokenów API dla niestandardowych tras tła projektu jest mylone metodami. Token z uprawnieniem projects.background może usunąć tło projektu, podczas gdy token z projects.background_delete jest odrzucany, co stanowi obejście autoryzacji tokenu.

W Vikunja w wersjach przed 2.3.0 endpoint importu plików używa kontrolowanego przez atakującego pola Size z metadanych JSON wewnątrz importowanego zipa zamiast rzeczywistego rozmiaru zdekompresowanej zawartości do sprawdzania limitu rozmiaru pliku. Ustawienie Size na 0 przy dużych skompresowanych wpisach w zipie omija skonfigurowany limit maksymalnego rozmiaru pliku.

Vikunja przed wersją 2.3.0 generuje wpisy VTODO iCalendar poprzez konkatenację ciągów bez escapowania wartości TEXT zgodnie z RFC 5545. Tytuły zadań zawierające CRLF mogą łamać granice właściwości i wstrzykiwać dowolne właściwości iCalendar, takie jak ATTACH, VALARM lub ORGANIZER.

W Vikunja przed wersją 2.3.0 tytuły zadań są osadzane bezpośrednio w składni linków Markdown w powiadomieniach e-mail o zaległych zadaniach, bez escapowania znaków specjalnych Markdown. Po renderowaniu przez goldmark i sanityzacji przez bluemonday (który zezwala na tagi <a> i <img>) wstrzyknięte konstrukcje Markdown tworzą linki phishingowe i piksele śledzące w legalnych e-mailach powiadomień. Podatność naprawiono w wersji 2.3.0.

W Vikunja w wersjach przed 2.3.0 funkcja addRepeatIntervalToTime używa pętli O(n) przesuwającej datę o interwał RepeatAfter aż przekroczy bieżący czas. Utworzenie zadania cyklicznego z interwałem 1 sekundy i datą wykonania daleko w przeszłości powoduje miliardy iteracji, obciążając CPU i blokując połączenie do bazy danych na minuty przy każdym żądaniu.

W Vikunja przed wersją 2.3.0 metody CalDAV GetResource i GetResourcesByList pobierają zadania po UID z bazy danych bez weryfikacji, czy uwierzytelniony użytkownik ma dostęp do projektu zadania. Każdy uwierzytelniony użytkownik CalDAV znający UID zadania może odczytać pełne dane zadania z dowolnego projektu.

Vikunja to open-source'owa platforma do zarządzania zadaniami hostowana samodzielnie. Przed wersją 2.3.0 mechanizm blokady po nieudanych próbach TOTP był nieskuteczny z powodu błędu obsługi transakcji bazodanowej: po nieudanej walidacji TOTP handler logowania wywołuje HandleFailedTOTPAuth, a następnie bezwarunkowo wykonuje rollback, co cofa zapis StatusAccountLocked, umożliwiając nieograniczone próby brute-force kodów TOTP; problem naprawiono w wersji 2.3.0.

Vikunja w wersjach przed 2.3.0 zawiera błąd pierwszeństwa operatorów SQL w funkcji hasAccessToLabel, który pozwala każdemu uwierzytelnionemu użytkownikowi odczytać dowolną etykietę mającą co najmniej jedno powiązanie z zadaniem, niezależnie od uprawnień do projektu. Ujawniane są tytuły, opisy, kolory etykiet oraz informacje o twórcy. Podatność naprawiono w wersji 2.3.0.

Vikunja to open-source'owa platforma do zarządzania zadaniami. W wersjach przed 2.3.0 uwierzytelnianie linków współdzielenia (GetLinkShareFromClaims w pkg/models/link_sharing.go) buduje obiekty autoryzacji wyłącznie na podstawie oświadczeń JWT, bez walidacji po stronie serwera w bazie danych. Gdy właściciel projektu usunie link współdzielenia lub obniży uprawnienia, wcześniej wydane JWT nadal przyznają pierwotny poziom uprawnień przez maksymalnie 72 godziny.