CVE-2026-43976

wger, a free workout and fitness manager, prior to version 2.6 contains a vulnerability allowing a user with only the `gym_trainer` permission to deactivate any account in the same gym, including `gym_manager` and `general_gym_manager` accounts. The `UserDeactivateView` grants access to anyone holding any one of `gym.manage_gym`, `gym.manage_gyms`, or `gym.gym_trainer` (OR logic) without privilege-hierarchy checks. Version 2.6 fixes the issue.

In wger prior to version 2.6, the trainer_login view accepts GET requests and executes django_login() without CSRF protection, because Django's CsrfViewMiddleware only enforces tokens on unsafe methods. An attacker can embed an <img> tag on a malicious page; when an authenticated trainer loads it, their browser auto-issues the GET with the session cookie, forcibly rebinding the trainer's session to an arbitrary user account.

In wger prior to version 2.6, there is a vulnerability that allows a user with gym.manage_gym permissions to reset the password of any user with no gym assignment. By exploiting an object comparison error, an attacker can take over the victim's account, and the victim's original password is invalidated.

In wger prior to version 2.6, an authenticated attacker can inject arbitrary workout log entries into any other user's SlotEntry by supplying the victim's slot_entry ID in a POST /api/v2/workoutlog/ request. The slot_entry foreign key is not included in ownership verification, and the injected data is silently folded into the victim's progressive-overload calculations, corrupting auto-generated targets.

In wger prior to version 2.6, a vulnerability in the authentication/session lifecycle allows bearer-style API credentials to remain valid after a user logs out and after a password change. An attacker who steals a DRF authtoken or JWT refresh token can continue to access protected /api/v2/* endpoints until the token is manually rotated/deleted or naturally expires.

wger before 2.6 fails to sanitize first_name and last_name fields in the gym member TSV export endpoint, allowing any gym member to inject spreadsheet formulas. Attackers can inject formulas like =HYPERLINK to exfiltrate admin data or execute code when admins open the exported file in Excel or LibreOffice Calc.

wger before 2.6 (affected versions <= 2.5.0) contains an open redirect vulnerability in the trainer_login view (wger/core/views/user.py). After a trainer enters impersonation mode, the view redirects to the user-supplied 'next' GET parameter via HttpResponseRedirect() without validating it with url_has_allowed_host_and_scheme(). An attacker who delivers a crafted link to an authenticated trainer can redirect the trainer's browser to an attacker-controlled domain, enabling phishing and leaking the wger URL structure (including the impersonated user's user_pk) via the Referer header.

wger before 2.5 fails to validate the maximum duration of routine date ranges, allowing authenticated users to create routines spanning arbitrarily long periods. Attackers can trigger the date_sequence computation via routine detail endpoints, forcing the server to iterate thousands of times per request and exhaust worker threads, denying service to legitimate users.

wger versions through master contain an incomplete authorization bypass in wger/core/views/user.py where three views retain the original gym-scope check using raw integer comparison instead of the is_same_gym() helper, allowing gym staff with gym=None to delete, deactivate, or activate any other user with gym=None. Attackers with gym.manage_gym permission and gym=None affiliation can permanently delete user accounts, lock users out via deactivation, or undo defensive deactivations by exploiting the None != None comparison edge case.

A flaw was found in wger-project wger up to 2.6.0-alpha2 in the function reset_user_password of the file wger/gym/views/gym.py in the Password Reset component. Executing a manipulation can lead to cross-site request forgery. The attack can be launched remotely. A patch is recommended.