CVE-2026-111921

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