Summary
jshERP through version 3.6 contains an authorization bypass in the password reset endpoint, allowing an authenticated user to reset another user's password. By supplying a different target account identifier, an attacker may gain access to user accounts, including administrative accounts.
Affected context
The vulnerability occurs in jshERP deployments through version 3.6 when the POST /user/resetPwd endpoint accepts a caller-provided target user ID without adequately verifying that the authenticated caller is authorized to manage that account. The risk is greatest where ordinary authenticated users can reach the endpoint and password resets use a predictable or known default value.
Exploit preconditions
- Attack surface: The authenticated password-reset API endpoint - Required access: A valid jshERP user session or equivalent authenticated access - Trigger point: Processing a password-reset request for a selected account - Why exploitation is possible: The endpoint may trust the supplied target
user identifier without enforcing an object-level authorization check
Why this happens
The underlying bug is missing or ineffective object-level authorization on a state-changing password-management operation. The application appears to authenticate the requester but does not reliably confirm that the requester is permitted to modify the referenced account, which maps to CWE-862: Missing Authorization. Using a caller-controlled account identifier in a privileged operation without an ownership or role check creates an authorization boundary failure.
Potential impact
- An attacker may take over other user accounts
- Administrative accounts could be compromised
- Unauthorized users could access protected business data
- Attackers could alter records or perform actions under another identity
- Account recovery and audit integrity could be undermined
General mitigation guidance
Mitigation generally centers on enforcing authorization at the endpoint and service layers, rather than relying only on authentication. Password-reset operations should use secure-by-default authorization policies, verify that the requester has permission to manage the specific target account, and restrict administrative actions to appropriately privileged roles. Systems should reduce trust in caller-supplied identifiers, avoid predictable default passwords, use controlled recovery flows with sufficiently strong verification, and record security-relevant reset events for review.
How teams detect issues like this
Detection approaches include static analysis and code review for password or account-management methods that accept arbitrary user identifiers without nearby authorization checks. Reviewers can look for direct database updates based on request parameters, missing ownership or role validation, and default credentials generated during reset flows. Runtime monitoring can flag unusual password resets across many accounts, resets by low-privilege users, and administrative-account changes initiated from unexpected sessions. Automated code-review tools and policy checks may help identify missing object-level authorization patterns.
