Podatności Vikunja

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.

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.

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.

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ń.

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.

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.