Summary
A broken authorization vulnerability in cool-admin-midway allows department-limited administrators to access and manage users outside their assigned departments by supplying arbitrary user IDs.
An attacker with the relevant sys:user:* permissions may read user records, reset passwords or roles, and delete accounts when server-side authorization does not verify departmental ownership.
A broken authorization vulnerability in cool-admin-midway allows department-limited administrators to access and manage users outside their assigned departments by supplying arbitrary user IDs.
An attacker with the relevant sys:user:* permissions may read user records, reset passwords or roles, and delete accounts when server-side authorization does not verify departmental ownership.
Affected context
The vulnerability occurs in administrative user-management endpoints when access decisions rely on the caller's general user-management permissions but do not also enforce department-level scope. Affected operations include user information access, updates, and deletion through endpoints such as /admin/sys/user/info, with risk depending on deployment configuration and assigned permissions.
The vulnerability occurs in administrative user-management endpoints when access decisions rely on the caller's general user-management permissions but do not also enforce department-level scope. Affected operations include user information access, updates, and deletion through endpoints such as /admin/sys/user/info, with risk depending on deployment configuration and assigned permissions.
Exploit preconditions
- Attack surface: Administrative user-management API endpoints
- Required access: An authenticated account holding applicable
sys:user:*permissions - Trigger point: Supplying a user ID belonging to another department when requesting user information or performing update or delete operations
- Why exploitation is possible: The authorization logic may validate the operation permission without confirming that the target user falls within the administrator's permitted department scope
- Attack surface: Administrative user-management API endpoints
- Required access: An authenticated account holding applicable
sys:user:*permissions - Trigger point: Supplying a user ID belonging to another department when requesting user information or performing update or delete operations
- Why exploitation is possible: The authorization logic may validate the operation permission without confirming that the target user falls within the administrator's permitted department scope
Why this happens
The underlying flaw is an incomplete authorization check, mapped to CWE-639: Authorization Bypass Through User-Controlled Key. The application uses a caller-controlled identifier to select a user record but does not consistently bind that identifier to the caller's authorized department or resource scope. As a result, a valid permission can be incorrectly treated as sufficient authority over records outside the administrator's assigned boundaries.
The underlying flaw is an incomplete authorization check, mapped to CWE-639: Authorization Bypass Through User-Controlled Key. The application uses a caller-controlled identifier to select a user record but does not consistently bind that identifier to the caller's authorized department or resource scope. As a result, a valid permission can be incorrectly treated as sufficient authority over records outside the administrator's assigned boundaries.
Potential impact
- Unauthorized disclosure of user records may occur
- Passwords or roles could be reset for users in other departments
- Accounts may be deleted without appropriate departmental authority
- Administrative boundaries may be weakened
- Compromised accounts could enable further unauthorized access
- Unauthorized disclosure of user records may occur
- Passwords or roles could be reset for users in other departments
- Accounts may be deleted without appropriate departmental authority
- Administrative boundaries may be weakened
- Compromised accounts could enable further unauthorized access
General mitigation guidance
Mitigation typically focuses on enforcing object-level authorization for every user-management operation.
Common defensive patterns include:
- Recalculate the caller's permitted department scope on the server for each request
- Verify target-user ownership or department membership before reading, updating, or deleting records
- Avoid treating client-supplied user IDs as proof of authorization
- Apply deny-by-default policies for cross-department operations
- Separate sensitive actions such as password and role changes behind additional privilege checks
- Use service accounts and administrative roles with the minimum permissions required
- Log and review cross-scope authorization failures and sensitive account-management events
Mitigation typically focuses on enforcing object-level authorization for every user-management operation.
Common defensive patterns include:
- Recalculate the caller's permitted department scope on the server for each request
- Verify target-user ownership or department membership before reading, updating, or deleting records
- Avoid treating client-supplied user IDs as proof of authorization
- Apply deny-by-default policies for cross-department operations
- Separate sensitive actions such as password and role changes behind additional privilege checks
- Use service accounts and administrative roles with the minimum permissions required
- Log and review cross-scope authorization failures and sensitive account-management events
How teams detect issues like this
Organizations can detect similar issues through:
- Static analysis and code review checks for authorization decisions based only on user-controlled identifiers
- Review of controller and service methods to confirm object-level checks occur before database reads or mutations
- Tests that exercise valid permissions against users inside and outside the caller's department
- API policy enforcement requiring resource-scope validation for every user-management action
- Monitoring for repeated access attempts involving out-of-scope user IDs and unexpected role, password, or deletion changes
Automated application-security testing can help identify missing authorization checks when tests include multiple departments and privilege levels.
Organizations can detect similar issues through:
- Static analysis and code review checks for authorization decisions based only on user-controlled identifiers
- Review of controller and service methods to confirm object-level checks occur before database reads or mutations
- Tests that exercise valid permissions against users inside and outside the caller's department
- API policy enforcement requiring resource-scope validation for every user-management action
- Monitoring for repeated access attempts involving out-of-scope user IDs and unexpected role, password, or deletion changes
Automated application-security testing can help identify missing authorization checks when tests include multiple departments and privilege levels.
