CVE-2026-94412 in jshERP
Summary
by MITRE • 09/21/2026
jshERP through 3.6 contains an authorization bypass vulnerability in the POST /user/resetPwd endpoint that allows authenticated users to reset any other user's password. Attackers can submit a request with an arbitrary target user ID to reset that account's password to a known default value, enabling unauthorized access to other user accounts including administrators.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/21/2026
The vulnerability identified in jshERP versions through 3.6 represents a critical failure in server-side access control mechanisms, specifically manifesting as an authorization bypass within the password reset functionality. This flaw is categorized under CWE-285, which describes Improper Access Control, and aligns with MITRE ATT&CK technique T1078, Valid Accounts, as it allows attackers to leverage existing authentication credentials to escalate privileges or access restricted resources. The core technical issue resides in the POST /user/resetPwd endpoint, where the application fails to validate that the user initiating the password reset request is authorized to modify the account specified in the payload. Instead of binding the reset operation strictly to the authenticated session's identity, the server trusts the target identifier provided by the client-side input without performing a secondary authorization check against its internal access control policies.
From an operational perspective, this architectural flaw enables any authenticated user, regardless of their role or privilege level within the jshERP system, to arbitrarily select a victim user ID and submit it in the request body. Upon receiving such a request, the backend processes the reset action for the specified target account rather than restricting the operation to the currently logged-in user's profile. Consequently, an attacker can successfully overwrite the password of any other account, including high-privilege administrative accounts, by supplying that account's unique identifier in the POST parameters. The system typically resets the targeted account to a known default or predictable value, which significantly lowers the barrier for subsequent unauthorized access attempts since the attacker does not need to guess complex credentials but merely needs to know the target user ID and apply the standard reset procedure.
The impact of this vulnerability extends beyond simple credential compromise; it fundamentally undermines the integrity of the application's multi-tenant security model if applicable, or allows lateral movement within a single organization's ERP environment. An attacker with low-level access can pivot to administrative roles by resetting an admin password, thereby gaining full control over sensitive business data, financial records, and system configurations stored within jshERP. This capability facilitates comprehensive data exfiltration, manipulation of critical enterprise workflows, and potential persistence mechanisms that are difficult to detect without rigorous monitoring of authentication logs for anomalous reset patterns originating from non-administrative accounts.
To mitigate this vulnerability, developers must implement strict server-side authorization checks on the POST /user/resetPwd endpoint. The application should verify that the user ID present in the request payload matches the subject identifier associated with the active session token or cookie before processing any password modification logic. Additionally, implementing role-based access control (RBAC) constraints can restrict this specific functionality to administrative users only, ensuring that standard employees cannot trigger resets for other accounts regardless of whether they provide a valid user ID. Security headers and input validation should also be employed to prevent related injection attacks, but the primary remediation lies in enforcing identity verification at the business logic layer rather than relying solely on client-side restrictions or session binding assumptions. Regular security audits focusing on broken object level authorization (BOLA) patterns are recommended to identify similar flaws across other endpoints within the application ecosystem.