Summary
ELADMIN v2.7 and earlier does not adequately authorize password-reset requests sent to the user-management endpoint. Any authenticated user may be able to reset passwords for arbitrary accounts, including the built-in administrator, when the endpoint is reachable.
ELADMIN v2.7 and earlier does not adequately authorize password-reset requests sent to the user-management endpoint. Any authenticated user may be able to reset passwords for arbitrary accounts, including the built-in administrator, when the endpoint is reachable.
Affected context
The issue occurs in the ELADMIN user-management API, specifically the password-reset operation exposed through PUT /api/users/resetPwd. The endpoint lacks the method-level authorization check used by other user-management operations, and the service logic does not enforce role-based or ownership constraints before changing the selected user's password.
The issue occurs in the ELADMIN user-management API, specifically the password-reset operation exposed through PUT /api/users/resetPwd. The endpoint lacks the method-level authorization check used by other user-management operations, and the service logic does not enforce role-based or ownership constraints before changing the selected user's password.
Exploit preconditions
- Attack surface: Authenticated HTTP access to the user-management password-reset endpoint
- Required access: A valid account with any application role
- Trigger point: Processing a password-reset request for a selected user
- Why exploitation is possible: The endpoint and service operation do not consistently verify whether the caller is authorized to manage the targeted account
- Attack surface: Authenticated HTTP access to the user-management password-reset endpoint
- Required access: A valid account with any application role
- Trigger point: Processing a password-reset request for a selected user
- Why exploitation is possible: The endpoint and service operation do not consistently verify whether the caller is authorized to manage the targeted account
Why this happens
The vulnerability is caused by an authorization gap in a security-sensitive account-management operation. Although surrounding user-management endpoints apply method-level access checks, the password-reset operation lacks equivalent authorization enforcement and does not validate the caller's role or ownership relationship with the target account. This is consistent with CWE-862: Missing Authorization, where an application performs a protected action without confirming that the requester has the required permission.
The vulnerability is caused by an authorization gap in a security-sensitive account-management operation. Although surrounding user-management endpoints apply method-level access checks, the password-reset operation lacks equivalent authorization enforcement and does not validate the caller's role or ownership relationship with the target account. This is consistent with CWE-862: Missing Authorization, where an application performs a protected action without confirming that the requester has the required permission.
Potential impact
- An authenticated user may reset another user's password
- An attacker could take over privileged or administrative accounts
- Account integrity and user access controls may be undermined
- The compromised account could be used for unauthorized data access or administrative actions
- An authenticated user may reset another user's password
- An attacker could take over privileged or administrative accounts
- Account integrity and user access controls may be undermined
- The compromised account could be used for unauthorized data access or administrative actions
General mitigation guidance
Mitigation generally focuses on making authorization mandatory for every sensitive account-management operation, including password resets.
Common defensive patterns include:
- Applying explicit method-level authorization checks to the password-reset operation
- Enforcing server-side role and ownership validation for the target account
- Denying self-service or cross-account actions unless the caller has a clearly defined administrative permission
- Using centralized, fail-closed authorization policies rather than relying on endpoint conventions
- Separating administrative password resets from user-initiated password changes
- Running authorization and access-control tests for privileged and cross-user workflows
- Limiting administrative privileges and protecting built-in administrator accounts with stronger controls
Mitigation generally focuses on making authorization mandatory for every sensitive account-management operation, including password resets.
Common defensive patterns include:
- Applying explicit method-level authorization checks to the password-reset operation
- Enforcing server-side role and ownership validation for the target account
- Denying self-service or cross-account actions unless the caller has a clearly defined administrative permission
- Using centralized, fail-closed authorization policies rather than relying on endpoint conventions
- Separating administrative password resets from user-initiated password changes
- Running authorization and access-control tests for privileged and cross-user workflows
- Limiting administrative privileges and protecting built-in administrator accounts with stronger controls
How teams detect issues like this
Organizations can identify similar weaknesses through:
- Static analysis and code review checks for sensitive endpoints without authorization annotations or policy calls
- Review of service methods that accept a target user identifier without validating caller ownership or role
- API authorization testing across roles, including attempts to act on other users' accounts
- Policy enforcement requiring explicit authorization controls for password, role, and account-status operations
- Audit-log monitoring for password resets initiated by unusual roles or targeting privileged accounts
Automated security review tools may help flag inconsistent authorization coverage between related endpoints.
Organizations can identify similar weaknesses through:
- Static analysis and code review checks for sensitive endpoints without authorization annotations or policy calls
- Review of service methods that accept a target user identifier without validating caller ownership or role
- API authorization testing across roles, including attempts to act on other users' accounts
- Policy enforcement requiring explicit authorization controls for password, role, and account-status operations
- Audit-log monitoring for password resets initiated by unusual roles or targeting privileged accounts
Automated security review tools may help flag inconsistent authorization coverage between related endpoints.
Sources
| Source | Link |
|---|---|
| github. | github.com/ |
| github. | github.com/ |
