CVE-2026-46434 in wger
Summary
by MITRE • 10/07/2026
wger is a free, open-source workout and fitness manager. Prior to version 2.6, a user with only the `gym_trainer` permission can 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 via `WgerMultiplePermissionRequiredMixin`), and performs no privilege-hierarchy check to prevent a lower-privileged role from disabling a higher-privileged one. Version 2.6 fixes the issue.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/07/2026
The vulnerability identified in wger, specifically prior to version 2.6, represents a critical Broken Access Control flaw that allows unauthorized elevation of privileges within the application's gym management structure. As an open-source workout and fitness manager, wger relies on role-based access control to maintain operational integrity among its users. The core issue stems from the implementation of the UserDeactivateView endpoint, which is protected by the WgerMultiplePermissionRequiredMixin class. This security middleware employs a logical OR operation when evaluating permissions, granting access if the authenticated user possesses any one of three specific privileges: gym.manage_gym, gym.manage_gyms, or gym.gym_trainer. While this design may be intended to streamline administrative tasks for various roles, it fails to account for the hierarchical nature of these permissions within a single gym environment.
In wger's permission model, there is a distinct hierarchy where general managers and gym managers hold higher levels of authority than trainers. A user with only the gym_trainer permission should logically be restricted from performing administrative actions that affect users with superior privileges. However, because the access control check relies on an OR condition rather than requiring specific permissions or validating role hierarchies, a trainer can successfully invoke the deactivation function for any account within their assigned gym. This includes accounts belonging to gym managers and general gym managers, who are responsible for overseeing operations, managing staff, and maintaining system configuration. The absence of a privilege-hierarchy check means that lower-privileged roles can effectively neutralize higher-privileged ones without authorization or oversight.
The operational impact of this vulnerability is severe, as it compromises the availability and integrity of administrative functions within the fitness management platform. An attacker with trainer-level access could disable manager accounts, thereby locking out legitimate administrators from managing the gym's settings, user base, and workout plans. This action can lead to significant disruption in business operations, loss of data accessibility for managers, and potential denial of service for other users who rely on the services managed by those disabled accounts. Furthermore, this flaw undermines trust in the system's security model, as it allows a relatively low-privileged user to exert control over high-level administrative functions, potentially facilitating further attacks such as account takeover or data manipulation if combined with other vulnerabilities.
From an industry standards perspective, this vulnerability aligns closely with CWE-269: Improper Privilege Management and CWE-862: Missing Authorization. The failure to enforce a proper hierarchy of privileges allows a lower-level entity to perform actions reserved for higher-level entities. In the context of the MITRE ATT&CK framework, this behavior is indicative of T1078: Valid Accounts, where an attacker uses legitimate credentials with insufficient restrictions to gain unauthorized access or control over system resources. The specific technique involves exploiting misconfigured access controls to escalate privileges and disrupt administrative processes.
To mitigate this vulnerability, organizations using wger must upgrade immediately to version 2.6 or later, which addresses the flawed permission logic by implementing proper privilege hierarchy checks within the UserDeactivateView. For environments where upgrading is not immediately feasible, temporary mitigations include restricting access to the deactivation endpoint through network-level controls if possible, auditing user permissions regularly to ensure no trainers have been inadvertently granted broader privileges than intended, and monitoring for unusual account activity such as sudden deactivations of manager accounts by trainer users. Regular security assessments and penetration testing should be conducted to identify similar misconfigurations in role-based access control systems across the application infrastructure.