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 w wersji od 2.2.0 do 2.7.1 zawiera podatność na wstrzykiwanie HTML w funkcji CreateConversationalHeader w pliku pkg/notifications/mail.go, która interpoluje nazwy wyświetlane oraz tytuły zadań i projektów bezpośrednio do kotwic e-mail. Uwierzytelnieni użytkownicy mogą tworzyć tytuły lub nazwy wyświetlane, które zamykają kotwicę i wstrzykują linki phishingowe do e-maili powiadamiających o komentarzach i wzmiankach w zadaniach wysyłanych do członków projektu.

Vikunja od 2.2.0 przed 2.7.0 zawiera permisywną konfigurację CORS, która ufa każdemu portowi localhost i 127.0.0.1 z poświadczeniami, nawet gdy ustawiono service.publicurl. Atakujący kontrolujący stronę na dowolnym porcie localhost może wysłać żądanie z poświadczeniami do endpointu odświeżania tokenu i odczytać zwrócony bearer JWT, aby przejąć konto zalogowanego użytkownika.

Vikunja w wersjach od 0.13.0 przed 2.7.0 zawiera błąd nieprawidłowej autoryzacji, który pozwala członkom projektu z uprawnieniem Write usuwać udziały linków na poziomie administratora. Sprawdzenie uprawnień do usunięcia odczytuje niezaładowany obiekt udziału, więc atakujący może wysyłać żądania DELETE do endpointów udziałów projektów v1 lub v2 z kolejnymi identyfikatorami, aby unieważnić linki administratora i istniejące sesje udziałów.

Vikunja 2.6.0 zawiera błąd kontroli dostępu w funkcji getProjectAccessForUser (pkg/models/project_access.go), która wyznacza efektywne uprawnienie użytkownika do projektu jako maksimum w drzewie projektów, nadpisując jawne udziały o niższych uprawnieniach w podprojektach. Współpracownik z prawem zapisu w projekcie nadrzędnym, ale tylko do odczytu w projekcie podrzędnym, może modyfikować zadania i zawartość tego podprojektu.

Vikunja w wersjach od 0.22.0 przed 2.7.0 zawiera błąd nieprawidłowego odbierania dostępu, który pozwala usuniętym współpracownikom nadal otrzymywać dane projektu przez utworzone przez nich webhooki. Byli współpracownicy nadal otrzymują tytuły i opisy zadań przez swój webhook, w tym treści utworzone po odebraniu im dostępu.

Vikunja od 1.0.0-rc0 przed 2.7.0 zawiera błąd nieprawidłowej autoryzacji w funkcji RecalculateTaskPositions, który pozwala uwierzytelnionym użytkownikom bez dostępu do jakichkolwiek projektów zapisywać wiersze task_positions dla wszystkich zadań w całej instancji. Atakujący mogą usunąć swój Inbox po zmianie default_project_id, a następnie tworzyć puste filtry zapisane, aby utrwalić odwołania między dzierżawcami i wzmocnić zapisy w celu przeprowadzenia ataku typu denial of service.

Vikunja w wersjach od 2.3.0 przed 2.7.0 zawiera błąd nieprawidłowej walidacji sesji, który pozwala atakującym zachować dostęp do WebSocket po odebraniu uprawnień, ponieważ funkcja handleAuth nigdy nie sprawdza roszczenia sid tokenu JWT względem tabeli sesji. Atakujący posiadający skradziony token dostępu może otwierać lub utrzymywać połączenia z /api/v2/ws po usunięciu sesji lub włączeniu TOTP, nadal otrzymując powiadomienia notification.created ofiary, w tym treści komentarzy, zadań i projektów.

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.

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.

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.

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.

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.