Summary
A privilege-management flaw in wger before version 2.6 allows a user with only the gym_trainer permission to deactivate other accounts in the same gym.
Because the authorization check accepts several permissions with OR logic and does not enforce role hierarchy, a lower-privileged user may disable gym_manager or general_gym_manager accounts.
A privilege-management flaw in wger before version 2.6 allows a user with only the gym_trainer permission to deactivate other accounts in the same gym.
Because the authorization check accepts several permissions with OR logic and does not enforce role hierarchy, a lower-privileged user may disable gym_manager or general_gym_manager accounts.
Affected context
The issue occurs in wger deployments before version 2.6 when the UserDeactivateView is used to deactivate accounts within a gym. The view accepts any one of several gym-related permissions but does not verify that the acting user has authority equal to or greater than the target account.
The issue occurs in wger deployments before version 2.6 when the UserDeactivateView is used to deactivate accounts within a gym. The view accepts any one of several gym-related permissions but does not verify that the acting user has authority equal to or greater than the target account.
Exploit preconditions
- Attack surface: The account-deactivation functionality exposed by the application
- Required access: An authenticated account with the
gym_trainerpermission - Target condition: The target account belongs to the same gym and may have a higher-privileged role
- Trigger point: A request to the
UserDeactivateView - Why exploitation is possible: Authorization uses OR logic across permissions without a privilege-hierarchy or target-role check
- Attack surface: The account-deactivation functionality exposed by the application
- Required access: An authenticated account with the
gym_trainerpermission - Target condition: The target account belongs to the same gym and may have a higher-privileged role
- Trigger point: A request to the
UserDeactivateView - Why exploitation is possible: Authorization uses OR logic across permissions without a privilege-hierarchy or target-role check
Why this happens
The underlying bug is an authorization design failure in which possession of any accepted permission is treated as sufficient to perform a sensitive action. The implementation does not compare the requester's role with the target user's role or enforce a minimum authority level before deactivation.
This maps to CWE-269: Improper Privilege Management, because the application permits a lower-privileged principal to perform an administrative operation against a higher-privileged account.
The underlying bug is an authorization design failure in which possession of any accepted permission is treated as sufficient to perform a sensitive action. The implementation does not compare the requester's role with the target user's role or enforce a minimum authority level before deactivation.
This maps to CWE-269: Improper Privilege Management, because the application permits a lower-privileged principal to perform an administrative operation against a higher-privileged account.
Potential impact
- A gym trainer may deactivate manager accounts
- Administrative users may lose access to the application
- Gym operations and account administration could be disrupted
- An attacker could cause denial of service for affected users
- Recovery and incident-response workloads may increase
- A gym trainer may deactivate manager accounts
- Administrative users may lose access to the application
- Gym operations and account administration could be disrupted
- An attacker could cause denial of service for affected users
- Recovery and incident-response workloads may increase
General mitigation guidance
Mitigation generally focuses on enforcing explicit authorization boundaries for sensitive account actions.
Common defensive patterns include:
- Require a dedicated permission or role for account deactivation
- Enforce privilege hierarchy checks between the acting user and target account
- Deny self-service or cross-role administrative actions unless explicitly intended
- Apply least privilege to gym-level roles and administrative functions
- Use deny-by-default authorization for destructive account operations
- Centralize authorization decisions so role comparisons are consistently applied
- Treat permission combinations as security policy rather than relying on broad OR logic
Mitigation generally focuses on enforcing explicit authorization boundaries for sensitive account actions.
Common defensive patterns include:
- Require a dedicated permission or role for account deactivation
- Enforce privilege hierarchy checks between the acting user and target account
- Deny self-service or cross-role administrative actions unless explicitly intended
- Apply least privilege to gym-level roles and administrative functions
- Use deny-by-default authorization for destructive account operations
- Centralize authorization decisions so role comparisons are consistently applied
- Treat permission combinations as security policy rather than relying on broad OR logic
How teams detect issues like this
Organizations can identify similar issues through:
- Static analysis and code review of authorization mixins and permission decorators
- Review of destructive endpoints for missing target-resource authorization checks
- Tests that attempt lower-privileged actions against higher-privileged accounts
- Policy checks requiring explicit role-hierarchy validation for administrative operations
- Audit-log monitoring for account deactivations performed by unexpected roles
- Automated security review tools that flag broad OR-based permission checks
Organizations can identify similar issues through:
- Static analysis and code review of authorization mixins and permission decorators
- Review of destructive endpoints for missing target-resource authorization checks
- Tests that attempt lower-privileged actions against higher-privileged accounts
- Policy checks requiring explicit role-hierarchy validation for administrative operations
- Audit-log monitoring for account deactivations performed by unexpected roles
- Automated security review tools that flag broad OR-based permission checks
Sources
| Source | Link |
|---|---|
| github. | github.com/ |
| github. | github.com/ |
