CVE-2026-43977

wger, menedżer treningów i fitnessu, przed wersją 2.6 zawiera podatność, która pozwala użytkownikowi z uprawnieniem `gym_trainer` dezaktywować dowolne konto w tej samej siłowni, w tym konta `gym_manager` i `general_gym_manager`. Widok `UserDeactivateView` przyznaje dostęp każdemu posiadającemu którekolwiek z uprawnień `gym.manage_gym`, `gym.manage_gyms` lub `gym.gym_trainer` (logika OR), bez sprawdzania hierarchii uprawnień, co pozwala niższej roli wyłączyć wyższą. Wersja 2.6 naprawia problem.

W wger przed wersją 2.6 widok trainer_login akceptuje żądania GET i wykonuje django_login() bez ochrony CSRF, ponieważ oprogramowanie pośredniczące Django egzekwuje tokeny tylko dla metod niebezpiecznych. Atakujący może umieścić znacznik <img> na złośliwej stronie; gdy uwierzytelniony trener ją załaduje, jego przeglądarka automatycznie wyśle żądanie GET z ciasteczkiem sesji, wymuszając ponowne powiązanie sesji z dowolnym kontem użytkownika.

W wger przed wersją 2.6 występuje podatność, która pozwala użytkownikowi z uprawnieniami gym.manage_gym na zresetowanie hasła dowolnego użytkownika bez przypisania do siłowni. Wykorzystując błąd w porównaniu obiektów, atakujący może przejąć konto ofiary, a oryginalne hasło ofiary zostaje unieważnione.

W wger przed wersją 2.6 uwierzytelniony atakujący może wstrzyknąć dowolne wpisy dziennika treningowego do SlotEntry innego użytkownika, podając identyfikator slot_entry ofiary w żądaniu POST /api/v2/workoutlog/. Klucz obcy slot_entry nie jest weryfikowany pod kątem własności, a dane są włączane do obliczeń przeciążenia progresywnego ofiary, zaburzając automatycznie generowane cele.

W wger przed wersją 2.6 występuje luka w cyklu życia uwierzytelniania/sesji, gdzie tokeny API typu bearer pozostają ważne po wylogowaniu użytkownika i po zmianie hasła. Atakujący, który ukradnie token DRF lub JWT refresh, może nadal uzyskiwać dostęp do chronionych punktów końcowych /api/v2/* aż do ręcznego unieważnienia lub naturalnego wygaśnięcia tokenu.

wger przed wersją 2.6 zawiera podatność w pięciu widokach zarządzania siłownią, gdzie zabezpieczenie zakresu siłowni (`gym_a != gym_b`) jest błędnie pomijane, gdy oba operandy są `None`. Trener z uprawnieniami `gym.gym_trainer` i `gym.add_adminusernote` oraz bez przypisanej siłowni (`gym=None`) może czytać prywatne notatki administratora, przesłane dokumenty, umowy siłowni, konfigurację użytkownika i dane uprawnień dowolnego innego użytkownika w instancji. Zapytania filtrują tylko po `member_id` bez dodatkowej walidacji zakresu siłowni, co ujawnia wszystkie rekordy. Wersja 2.6 naprawia problem.

wger przed wersją 2.6 nie dezynfekuje pól first_name i last_name w punkcie eksportu TSV członków siłowni, co pozwala każdemu członkowi siłowni na wstrzyknięcie formuł arkusza kalkulacyjnego. Atakujący mogą wstrzyknąć formuły takie jak =HYPERLINK, aby wyeksfiltrować dane administratora lub wykonać kod, gdy administratorzy otworzą wyeksportowany plik w Excelu lub LibreOffice Calc.

wger przed wersją 2.6 (dotknięte wersje <= 2.5.0) zawiera podatność na otwarte przekierowanie w widoku trainer_login (wger/core/views/user.py). Po wejściu trenera w tryb personifikacji, widok przekierowuje na parametr 'next' dostarczony przez użytkownika za pomocą HttpResponseRedirect() bez walidacji przez url_has_allowed_host_and_scheme(). Atakujący, który dostarczy spreparowany link uwierzytelnionemu trenerowi, może przekierować przeglądarkę trenera na domenę kontrolowaną przez atakującego, co umożliwia phishing i wyciek struktury URL wger (w tym user_pk personifikowanego użytkownika) przez nagłówek Referer.

wger przed wersją 2.5 nie waliduje maksymalnego czasu trwania zakresów dat rutyn, co pozwala uwierzytelnionym użytkownikom tworzyć rutyny obejmujące dowolnie długie okresy. Atakujący mogą wywołać obliczenia date_sequence za pomocą punktów końcowych szczegółów rutyny, zmuszając serwer do iteracji tysięcy razy na żądanie i wyczerpując wątki robocze, co prowadzi do odmowy usługi dla legalnych użytkowników.

wger w wersjach do master zawiera niekompletne obejście autoryzacji w wger/core/views/user.py, gdzie trzy widoki zachowują oryginalne sprawdzanie zakresu siłowni przy użyciu surowego porównania liczb całkowitych zamiast pomocnika is_same_gym(), co pozwala personelowi siłowni z gym=None na usuwanie, dezaktywację lub aktywację dowolnego innego użytkownika z gym=None. Atakujący z uprawnieniami gym.manage_gym i przynależnością gym=None mogą trwale usuwać konta użytkowników, blokować użytkowników poprzez dezaktywację lub cofać defensywne dezaktywacje, wykorzystując przypadek brzegowy porównania None != None.