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 od wersji 1.0.0 przed 2.7.1 zawiera podatność na niekontrolowane zużycie zasobów, która pozwala uwierzytelnionym użytkownikom obejść limit service.maxitemsperpage poprzez wysyłanie page=0 do punktów końcowych listy /api/v1. Atakujący może samodzielnie się zarejestrować i wielokrotnie żądać page=0, wymuszając nieograniczone zapytania SQL, materializację pamięci i rozgałęzianie zapytań na wiersz, pogarszając dostępność dla innych użytkowników.

Vikunja w wersji przed 2.7.1 zawiera podatność polegającą na braku uwierzytelniania, która pozwala atakującym posiadającym skradzioną sesję na zarejestrowanie i włączenie TOTP bez hasła do konta. Atakujący mogą wywołać punkty końcowe rejestracji i włączenia TOTP z własnym sekretem, aby zablokować właściciela konta, co utrzymuje się nawet po resecie hasła.

Vikunja w wersji przed 2.7.1 zawiera podatność polegającą na przechowywanym wstrzyknięciu CSS, która pozwala uwierzytelnionym użytkownikom z uprawnieniami zapisu do projektu wstrzykiwać dowolny CSS poprzez nieoczyszczone atrybuty data-background-color komórek tabeli. Atakujący mogą przechowywać spreparowane opisy zadań lub komentarze, aby renderować nakładki phishingowe na cały widok lub wymuszać żądania tła bez kliknięcia, które deanonymizują przeglądających.

Vikunja w wersji przed 2.7.1 zawiera podatność polegającą na niewystarczającym wygasaniu sesji, która pozwala posiadaczom unieważnionych tokenów dostępu na dalsze uwierzytelnianie, ponieważ SetupTokenMiddleware pomija sprawdzanie sesji i statusu konta. Atakujący ze skradzionym tokenem może, po wylogowaniu, resecie hasła lub wyłączeniu konta, utworzyć sesje OAuth poprzez /oauth/authorize lub tokeny API tk_ w celu utrzymania trwałego dostępu.

Vikunja od wersji 2.4.0 przed 2.7.1 zawiera podatność polegającą na obejściu autoryzacji, która pozwala posiadaczom tokenów na wykonywanie niezamierzonych operacji z powodu kolidujących kluczy uprawnień tokenów API v1 i v2. Atakujący z tokenem o zakresie odczytu teł projektów może je usunąć poprzez trasę DELETE tła w v2, a tokeny z uprawnieniem tylko do tworzenia bucketów mogą aktualizować istniejące buckety.

Vikunja przed wersją 2.7.1 zawiera podatność mass assignment, która pozwala każdemu uwierzytelnionemu użytkownikowi ustawić pole external_id (tylko do odczytu) poprzez endpointy tworzenia i aktualizacji zespołu. Atakujący może oznaczyć zespół, który tworzy lub administruje, jako zarządzany zewnętrznie, trwale blokując usuwanie członków i powodując usunięcie członków SSO przy następnym logowaniu.

Vikunja przed wersją 2.7.1 przydziela pamięć bez ograniczeń w importerach migracji Trello, Todoist i Microsoft To Do, które buforują pobierane zdalne załączniki i odpowiedzi API w pamięci bez limitów rozmiaru. Uwierzytelnieni użytkownicy mogą rozpocząć migrację odwołującą się do ogromnych załączników lub powodującą zbyt duże odpowiedzi API, wyczerpując pamięć i powodując awarię współdzielonego procesu API dla wszystkich dzierżawców.

Vikunja od wersji 0.23.0 przed 2.7.1 zawiera podatność ujawnienia informacji, która pozwala współpracownikom projektu z prawem zapisu odczytywać zadania z niedostępnych projektów poprzez rejestrowanie webhooków. Ponieważ ładunki webhooków są budowane z uprawnieniami użytkownika wyzwalającego, atakujący otrzymują tytuły, opisy i metadane related_tasks z prywatnych projektów, gdy inny użytkownik modyfikuje powiązane zadanie.

Vikunja przed wersją 2.7.1 zawiera podatność niekontrolowanego zużycia zasobów, która pozwala uwierzytelnionym użytkownikom wyczerpać pamięć serwera poprzez żądanie awatarów w wielu różnych rozmiarach. Atakujący mogą przesłać zaszumiony awatar i pobierać go w każdym rozmiarze do 1024, buforując około gigabajta na konto bez usuwania i powodując zabicie procesu API przez OOM.

Vikunja w wersjach przed 2.7.1 zawiera podatność na obejście autoryzacji, która pozwala uwierzytelnionym użytkownikom odczytać dowolne zadanie poprzez wstrzyknięcie spreparowanego obiektu zadania do przeniesienia w koszu Kanban bez operacji. Atakujący może ustawić task.id na zadanie ofiary i task.project_id na własny projekt, kierując pełną zawartość zadania do swojego webhooka i fałszując powiadomienia o wzmiankach.

Vikunja przed wersją 2.7.1 zawiera podatność niewłaściwego ograniczenia nadmiernych prób uwierzytelniania, która pozwala posiadaczom sesji na brute-force haseł kont poprzez nieograniczone endpointy ponownego uwierzytelniania. Atakujący ze skradzioną sesją może odgadnąć hasło poprzez /user/settings/totp/disable bez blokady, a następnie wyłączyć TOTP bez kodu, aby trwale przejąć konto.

Vikunja od wersji 0.18.0 przed 2.7.1 zawiera podatność na eskalację uprawnień, która pozwala właścicielom zespołów uzyskać uprawnienia administratora lub własność projektów udostępnionych w trybie tylko do odczytu poprzez usuwanie kont. Atakujący może utworzyć bota, dodać go do swojego zespołu i usunąć go przez punkt końcowy botów, wyzwalając ensureProjectAdminUser, aby awansować udziały tylko do odczytu i zablokować prawdziwego właściciela.

Vikunja przed wersją 2.7.1 zawiera podatność typu denial of service, która pozwala uwierzytelnionym użytkownikom wyczerpać pamięć procesu API poprzez przesyłanie importów WeKan lub vikunja-file bez limitu liczby elementów. Atakujący mogą przesłać plik JSON WeKan o rozmiarze ~22 MB z setkami tysięcy kart lub zduplikowanymi ID do endpointu migracji wekan, wywołując OOM i awarię instancji.

Vikunja przed wersją 2.7.1 zawiera podatność nieprawidłowej autoryzacji w TaskBucket.CanUpdate, która sprawdza dostęp zapisu do projektu bucketu i do zadania osobno, ale nigdy nie weryfikuje, czy oba należą do tego samego projektu. Uwierzytelnieni użytkownicy z prawem zapisu do dwóch projektów mogą przenieść zadanie do bucketu kanban innego projektu. Powoduje to trwałe wiersze task_buckets między projektami, które liczą się do limitów bucketów i, dla bucketów done, przełączają stan done zadania.

Vikunja przed wersją 2.7.1 zawiera podatność ujawnienia informacji, która pozwala uwierzytelnionym użytkownikom ustalić, czy prywatne zespoły istnieją, wywołując endpoint samodzielnego usunięcia członka zespołu. Atakujący mogą wysyłać żądania DELETE do /teams/{id}/members/{własna nazwa użytkownika} dla dowolnych ID zespołów i używać rozróżnialnych odpowiedzi, aby dowiedzieć się, czy zespół istnieje, jest zarządzany przez SSO, czy ma jednego członka.

Vikunja przed wersją 2.7.1 zawiera podatność wyczerpania zasobów w importerze ZIP vikunja-file, która pozwala uwierzytelnionym użytkownikom zużywać CPU i pamięć poprzez przesyłanie archiwów z nadmierną liczbą wpisów. Atakujący mogą przesyłać eksporty ZIP zawierające wiele pustych lub niebędących plikami wpisów, które omijają limity na wpis, zmuszając scanArchive do dwukrotnego przetwarzania każdego wpisu.

Vikunja przed wersją 2.7.1 zawiera podatność client-side request forgery, która pozwala użytkownikom z prawem zapisu zmusić klientów przeglądających do żądań adresów loopback lub LAN poprzez przechowywanie elementów img w tekście sformatowanym. Atakujący mogą umieszczać obrazy w zadaniach, komentarzach, opisach projektów lub importowanym Markdown, aby wywołać ślepe żądania GET do lokalnych usług i śledzić, kiedy przeglądający otwierają treść.

Vikunja przed wersją 2.7.1 zawiera podatność polegającą na nieprawidłowym czyszczeniu zasobów, która pozostawia archiwa eksportu pełnych danych osierocone na dysku po ponownych eksportach, nieudanych eksportach lub usunięciu konta. Uwierzytelnieni użytkownicy mogą wielokrotnie ponawiać eksporty zawierające wszystkie swoje załączniki, aby wyczerpać miejsce na dysku, a dane osobowe usuniętych użytkowników pozostają przechowywane bezterminowo.

Vikunja przed wersją 2.7.1 zawiera podatność polegającą na ujawnieniu poświadczeń, która pozwala atakującym ukraść przechowywane tokeny uwierzytelniania poprzez nakłonienie użytkowników do zmiany adresu URL API frontendu. Ponieważ funkcja checkAndSetApiUrl pozostawia tokeny localStorage niezależne od origin, token bearer oraz token odświeżania OAuth dla aplikacji desktopowej są wysyłane na serwer atakującego, umożliwiając przejęcie konta.

Vikunja przed wersją 2.7.1 osadza aktywne tokeny resetowania hasła, potwierdzenia e-mail i usunięcia konta w ciągu zapytania URL linków wysyłanych e-mailem, więc pełny URI żądania, wraz z tokenem, jest zapisywany w logu dostępu HTTP Vikunja oraz w logach reverse-proxy, gdy użytkownik kliknie link. Atakujący z dostępem do odczytu tych logów może odtworzyć niewykorzystany token resetowania hasła, aby przejąć konto, lub token usunięcia konta, aby potwierdzić usunięcie.

Vikunja przed wersją 2.7.1 zawiera podatność polegającą na niekontrolowanym zużyciu zasobów, która pozwala uwierzytelnionym klientom CalDAV tworzyć nieograniczone zadania zastępcze poprzez wysyłanie VTODO z tysiącami właściwości RELATED-TO. Atakujący mogą powtarzać nieznane powiązane UID w jednym żądaniu PUT, aby wygenerować tysiące wierszy zadań, relacji i zdarzeń, rozdymając bazę danych i przeciążając potok zdarzeń.

Vikunja w wersji przed 2.7.1 nie przypina ponownie ścieżek PluginsDir i LogPath do service.rootpath, co pozwala na ładowanie wtyczek i zapisywanie logów w katalogu roboczym procesu startowego. Lokalny atakujący z prawem zapisu do tego katalogu może podłożyć wtyczki ładowane do serwera lub odczytać niewłaściwie umieszczone logi, w tym audit.log.

Vikunja przed wersją 2.7.1 zawiera podatność polegającą na niekontrolowanym zużyciu zasobów, która pozwala zapisującym w projektach lub administratorom widoków tworzyć nieograniczoną liczbę kolumn kanban z powodu braku limitów liczby. Atakujący mogą utworzyć tysiące kolumn, przez co każde odczytanie kanban wykonuje zapytanie SELECT i COUNT zadań dla każdej kolumny, generując duże obciążenie bazy danych.

Vikunja w wersji przed 2.7.1 zawiera podatność łańcucha dostaw w celach wydania mage, które pobierają moduł xgo i obraz Docker poprzez zmienne referencje latest. Atakujący, który przejmie moduł xgo, obraz lub rejestr, może wstrzyknąć złośliwy kod do później budowanych binariów wydania dostarczanych z ważnym podpisem.

Vikunja od wersji 0.24.0 przed 2.7.1 zawiera podatność dereferencji wskaźnika nil, która pozwala administratorom projektu zepsuć widoki projektu poprzez zapisanie konfiguracji kubełka w trybie filtra z pustym filtrem. Ponieważ validateProjectViewFilters pomija wpisy nil, każde kolejne odczytanie widoku powoduje panikę w kodzie kanban i kolekcji zadań, zwracając HTTP 500 wszystkim członkom projektu.

Vikunja od wersji 2.2.0 przed 2.7.1 zawiera podatność polegającą na obejściu autoryzacji, która pozwala posiadaczom tokenów o zakresie tylko projects_webhooks zarządzać webhookami na poziomie użytkownika właściciela poprzez podanie user_id w treści żądania. Atakujący mogą zarejestrować webhooki użytkownika na własny odbiornik, aby uzyskać przypomnienia i ładunki zadań ze wszystkich projektów właściciela oraz odczytywać, zmieniać lub usuwać istniejące webhooki użytkownika.

Vikunja przed wersją 2.7.1 ma podatność związaną z niezabezpieczonymi uprawnieniami plików, ponieważ localStorage.Write tworzy bloby czytelne dla wszystkich. Lokalni atakujący na współdzielonym hoście mogą czytać załączniki, tła projektów i eksporty oraz skopiować bazę SQLite w celu złamania hashy haseł offline.

Vikunja od wersji 0.22.0 przed 2.7.1 ma podatność ujawniającą informacje, która pozwala członkom projektu z uprawnieniami tylko do odczytu przeglądać pełne adresy URL celów webhooków poprzez listowanie webhooków projektu. Atakujący mogą wyodrębnić tokeny webhooków przychodzących lub klucze API osadzone w wartościach target_url, aby publikować w kanałach odbiorczych lub ponownie używać kluczy do momentu ich rotacji.

Vikunja przed wersją 2.7.1 ma podatność polegającą na niewłaściwej autoryzacji w canDoBucket, która pozwala użytkownikom z prawem zapisu do projektu usuwać kosze poprzez niezgodny identyfikator widoku. Atakujący mogą zażądać usunięcia przez endpoint kosza innego widoku, aby obejść regułę ostatniego kosza, pozostawiając wiszące odwołania do domyślnych/wykonanych koszy i niespójne kosze zadań.

Vikunja przed wersją 2.7.1 ma podatność ujawniającą informacje, która pozwala czytelnikom logów uzyskać hashe udostępniania linków, ponieważ logger żądań zapisuje surowy URI trasy /shares/:share/auth. Atakujący z dostępem do logów Vikunja lub logów reverse proxy mogą ponownie użyć nie wygasających i niechronionych hasłem hashy udostępniania, aby uzyskać JWT projektu z uprawnieniami odczytu, zapisu lub administratora.

Vikunja przed wersją 2.7.1 ma podatność polegającą na niekontrolowanym zużyciu zasobów, która pozwala uwierzytelnionym użytkownikom wyczerpać pamięć serwera poprzez równoczesne dekodowanie obrazów podczas przesyłania awatarów i teł. Atakujący mogą wysłać kilka równoległych, małych, wysoce kompresowalnych plików PNG dekodowanych do 50 megapikseli każdy, doprowadzając proces API do presji pamięciowej lub zabicia przez OOM.

Vikunja przed wersją 2.7.1 ma podatność związaną z niezabezpieczonymi uprawnieniami plików, która pozwala lokalnym użytkownikom czytać archiwa zrzutów utworzone z uprawnieniami umask przez polecenie vikunja dump. Lokalni atakujący na współdzielonym hoście mogą odczytać czytelny dla wszystkich plik zip w rootpath, aby uzyskać konfigurację, hashe haseł, sekrety TOTP, tokeny i przechowywane pliki.

Vikunja w wersji 2.0.0 przed 2.7.1 akceptuje ciała formularzy na endpointach logowania /api/v2 i callback OIDC bez sprawdzania CSRF lub Origin, umożliwiając cross-site request forgery logowania. Atakujący posiadający konto może zwabić ofiarę na stronę wysyłającą poświadczenia atakującego lub kod OIDC, przełączając ofiarę na konto atakującego i ujawniając dane, które ofiara następnie dodaje.

Vikunja w wersji przed 2.7.1 zawiera podatność cross-site request forgery, która pozwala atakującym zaimportować swoje dane do konta ofiary, ponieważ wywołania zwrotne OAuth migracji Todoist, Microsoft To Do i Trello nie mają powiązanego parametru state. Atakujący może autoryzować własne konto, zachować nieużywany kod lub token wywołania zwrotnego i zwabić zalogowaną ofiarę do trasy wywołania zwrotnego migracji, aby automatycznie zaimportować wybrane przez atakującego projekty i zadania zawierające linki phishingowe.

Vikunja od wersji 2.4.0 przed 2.7.1 ma podatność polegającą na obejściu uwierzytelniania, która pozwala wyłączonym lub zablokowanym użytkownikom zachować dostęp poprzez tokeny API należące do ich użytkowników botów. Ponieważ walidacja tokenów sprawdza tylko status bota, atakujący posiadający wcześniej wygenerowane tokeny botów mogą nadal czytać i modyfikować współdzielone projekty poprzez API HTTP, CalDAV, MCP i kanały informacyjne.

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.