Summary
A flawed gym-scope authorization check in wger allows certain trainers without an assigned gym to access sensitive records belonging to unrelated users. An attacker with the required trainer and admin-note permissions may retrieve private notes, uploaded documents, contracts, user configuration, and permission data by supplying another user's identifier.
A flawed gym-scope authorization check in wger allows certain trainers without an assigned gym to access sensitive records belonging to unrelated users. An attacker with the required trainer and admin-note permissions may retrieve private notes, uploaded documents, contracts, user configuration, and permission data by supplying another user's identifier.
Affected context
The issue occurs in wger gym management views when a deployment uses the affected authorization logic and a trainer account has gym.gym_trainer and gym.add_adminusernote permissions but no gym assignment. The vulnerable views rely on a gym comparison that does not reject two None values, while subsequent querysets use the supplied member_id without applying an independent gym-scope restriction.
The issue occurs in wger gym management views when a deployment uses the affected authorization logic and a trainer account has gym.gym_trainer and gym.add_adminusernote permissions but no gym assignment. The vulnerable views rely on a gym comparison that does not reject two None values, while subsequent querysets use the supplied member_id without applying an independent gym-scope restriction.
Exploit preconditions
- Attack surface: Authenticated gym management web views
- Required access: A trainer account with
gym.gym_trainerandgym.add_adminusernotepermissions - Account condition: The attacker must not be assigned to a gym
- Trigger point: A request to one of the affected views using another user's identifier
- Why exploitation is possible: The guard treats two missing gym assignments as equivalent and permits processing, while downstream queries do not independently verify that the target user belongs to an authorized gym
- Attack surface: Authenticated gym management web views
- Required access: A trainer account with
gym.gym_trainerandgym.add_adminusernotepermissions - Account condition: The attacker must not be assigned to a gym
- Trigger point: A request to one of the affected views using another user's identifier
- Why exploitation is possible: The guard treats two missing gym assignments as equivalent and permits processing, while downstream queries do not independently verify that the target user belongs to an authorized gym
Why this happens
The underlying bug is an incomplete authorization boundary. The gym-scope guard compares two nullable values and allows the request when both are None, treating the absence of a gym relationship as if it were a valid matching scope. The later data queries trust the attacker-supplied member identifier without enforcing the same authorization relationship, which maps to CWE-863: Incorrect Authorization.
The underlying bug is an incomplete authorization boundary. The gym-scope guard compares two nullable values and allows the request when both are None, treating the absence of a gym relationship as if it were a valid matching scope. The later data queries trust the attacker-supplied member identifier without enforcing the same authorization relationship, which maps to CWE-863: Incorrect Authorization.
Potential impact
- Attackers may read private administrator notes
- Attackers could access uploaded user documents and gym contracts
- User configuration data may be disclosed
- User permission information can be exposed
- The confidentiality of unrelated users on the instance may be compromised
- Attackers may read private administrator notes
- Attackers could access uploaded user documents and gym contracts
- User configuration data may be disclosed
- User permission information can be exposed
- The confidentiality of unrelated users on the instance may be compromised
General mitigation guidance
Mitigation generally focuses on enforcing authorization at every data-access boundary rather than relying on a single preliminary guard.
Common defensive patterns include:
- Treating missing scope values as unauthorized unless an explicit policy permits access
- Requiring an authenticated user's gym relationship to match the target record
- Applying gym-scope predicates directly to every sensitive queryset
- Deriving the target user from trusted server-side relationships where possible instead of trusting a client-supplied identifier
- Using deny-by-default authorization and least-privilege permission assignments
- Centralizing and reusing authorization checks across related management views
Mitigation generally focuses on enforcing authorization at every data-access boundary rather than relying on a single preliminary guard.
Common defensive patterns include:
- Treating missing scope values as unauthorized unless an explicit policy permits access
- Requiring an authenticated user's gym relationship to match the target record
- Applying gym-scope predicates directly to every sensitive queryset
- Deriving the target user from trusted server-side relationships where possible instead of trusting a client-supplied identifier
- Using deny-by-default authorization and least-privilege permission assignments
- Centralizing and reusing authorization checks across related management views
How teams detect issues like this
Organizations can look for this class of issue through:
- Static analysis and code review checks for authorization comparisons involving nullable scope fields
- Review signals where a client-supplied identifier is used without a corresponding ownership or tenant predicate
- Tests covering unassigned users, mismatched gyms, and cross-tenant record access
- Policy checks requiring authorization filters on queries that return notes, documents, contracts, configuration, or permissions
- Integration tests that verify every sensitive view denies access when the requester and target user have no valid gym relationship
Automated security review tools may help identify missing authorization checks, but application-specific tenant and membership rules still require manual validation.
Organizations can look for this class of issue through:
- Static analysis and code review checks for authorization comparisons involving nullable scope fields
- Review signals where a client-supplied identifier is used without a corresponding ownership or tenant predicate
- Tests covering unassigned users, mismatched gyms, and cross-tenant record access
- Policy checks requiring authorization filters on queries that return notes, documents, contracts, configuration, or permissions
- Integration tests that verify every sensitive view denies access when the requester and target user have no valid gym relationship
Automated security review tools may help identify missing authorization checks, but application-specific tenant and membership rules still require manual validation.
Sources
| Source | Link |
|---|---|
| github. | github.com/ |
| github. | github.com/ |
