CVE-2026-46434: 
Python vulnerability analysis and mitigation

CVE-2026-46434 is an Improper Privilege Management vulnerability in wger, a free open-source workout and fitness manager, that allows an authenticated user with only the gym_trainer permission to deactivate any account within the same gym — including higher-privileged gym_manager and general_gym_manager accounts. It affects wger versions prior to 2.6 and was published on October 7, 2026. The vulnerability was reported by researcher KadirArslan and assigned GHSA-x249-cx55-2h87. It carries a CVSS v3.1 base score of 7.1 (High) (Github Advisory, wger Advisory).

The root cause is CWE-269 (Improper Privilege Management) arising from two flaws in the Django-based application. First, WgerMultiplePermissionRequiredMixin in wger/utils/generic_views.py (line 48) evaluates the permission_required tuple with OR logic — any single permission from ('gym.manage_gym', 'gym.manage_gyms', 'gym.gym_trainer') grants access to UserDeactivateView. Second, the dispatch() method in wger/core/views/user.py (line 378) only checks that the target user belongs to the same gym as the requester, but performs no privilege-hierarchy comparison to prevent a lower-privileged trainer from acting on a higher-privileged manager. The same flaw exists in UserActivateView (line 415). An additional contributing factor is that get_permission_list() in wger/gym/helpers.py always includes the trainer role as assignable, meaning a manager can unknowingly create a trainer account that later locks them out (wger Advisory, Github Advisory).

A malicious gym trainer can deactivate every gym_manager and general_gym_manager account within their gym by sending simple HTTP GET requests, effectively locking out all legitimate administrators. Deactivated managers cannot log in or perform any administrative tasks until a general_gym_manager (superadmin) or Django superuser manually reactivates their accounts. This constitutes a targeted denial-of-service against gym administration and an effective privilege escalation, as the trainer can seize de facto control of the gym's management functions. The vulnerability also enables an abuse chain where a manager unknowingly creates the trainer account that subsequently locks them out (wger Advisory).

A public proof-of-concept Python script is available in the GitHub security advisory, demonstrating the full attack flow using Django's test client to deactivate a manager account with only trainer credentials (wger Advisory). The exploit requires low privileges (a valid gym_trainer account in the same gym as the target) and no user interaction, making it straightforward to execute. There is no evidence of in-the-wild exploitation at this time, and no threat actor attribution has been reported. The EPSS score is approximately 0.221% (12th percentile), and the vulnerability is not listed in the CISA KEV catalog (Github Advisory).

1. Reconnaissance: Identify a wger instance running a version prior to 2.6. Confirm the attacker has or can obtain a gym_trainer account within the target gym.
2. Enumerate target user IDs: Log in to the wger application as the trainer. User IDs of gym managers may be visible in gym management interfaces or enumerable via the application's user listing features.
3. Authenticate as gym_trainer: Establish an authenticated session using the trainer's credentials (e.g., via the login endpoint or Django session).
4. Send deactivation request: Issue an HTTP GET request to the UserDeactivateView endpoint for the target manager's user ID:

   GET /en/user/<manager_user_id>/deactivate

5. Permission check bypass: The WgerMultiplePermissionRequiredMixin grants access because the trainer holds gym.gym_trainer (OR logic). The dispatch() method confirms same-gym membership but performs no privilege-hierarchy check.
6. Account deactivated: The view sets is_active = False on the target manager's account. The manager is immediately unable to log in.
7. Repeat for all managers: Repeat steps 4–6 for each gym_manager and general_gym_manager account in the gym to achieve full administrative lockout (wger Advisory, Github Advisory).

• Network: Repeated HTTP GET requests to /en/user/<id>/deactivate or /en/user/<id>/activate originating from a session authenticated as a gym_trainer role user; requests targeting multiple different user IDs in rapid succession.
• Logs: Web server access logs showing GET /en/user/*/deactivate with HTTP 200 responses from a trainer-role account; Django application logs recording multiple account deactivation events within a short timeframe.
• Application State: Multiple gym_manager or general_gym_manager accounts with is_active = False in the database that were not deactivated through normal administrative workflows; unexpected lockout of administrative users reported by gym managers.

The fix is available in wger version 2.6, which adds a privilege-hierarchy check to both UserDeactivateView.dispatch() and UserActivateView.dispatch() to prevent trainers from acting on accounts with equal or higher privileges (wger Release 2.6, Github Advisory). Upgrading to version 2.6 or later is the recommended remediation. As a temporary workaround until patching is possible, restrict the gym_trainer role to only fully trusted users and implement monitoring of account deactivation events within gym management systems. Organizations should also audit existing trainer accounts to identify any unauthorized deactivation activity.