Attack Chain

1. Attacker obtains or creates a user account assigned to the 'gym_trainer' group within a target gym.
2. Attacker logs into the wger platform using the trainer credentials.
3. Attacker identifies the user ID for a 'gym_manager' or 'general_gym_manager' account operating within the same gym instance.
4. Attacker constructs a malicious request to the UserDeactivateView endpoint, specifically GET /en/user/<manager_user_id>/deactivate.
5. The application validates the requester's 'gym_trainer' permission as sufficient for access to the view.
6. The dispatch() method confirms the trainer and the target manager belong to the same gym.
7. The application executes the deactivation logic without verifying if the target has higher privileges.
8. The victim manager account is set to is_active = False, resulting in immediate lockout.

Impact

Successful exploitation results in a persistent denial of service for administrative users. Managers are unable to log in, manage gym members, or perform administrative tasks until manual intervention by a 'general_gym_manager' or superuser occurs. This directly impacts the integrity and availability of gym management operations.

Recommendation

1. Upgrade to a version of wger that includes the privilege hierarchy check in UserDeactivateView and UserActivateView.
2. Audit current gym user roles and remove unnecessary 'gym_trainer' permissions until the patch is applied.
3. Implement strict monitoring for access to /deactivate or /activate endpoints by users who do not possess 'gym_manager' permissions.
4. Ensure all Django superuser or 'general_gym_manager' accounts are protected with multi-factor authentication to prevent lockout by compromised lower-privileged accounts.