CVE-2026-94413 in jshERP
Summary
by MITRE • 09/21/2026
jshERP through 3.6 fails to redact password hashes in the /user/info endpoint, allowing authenticated users to retrieve unsalted MD5 password digests for any user. Attackers can request arbitrary user information by supplying user IDs to obtain password hashes usable for offline cracking or direct authentication bypass.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/21/2026
The vulnerability identified in jshERP versions through 3.6 represents a critical failure in data sanitization and access control mechanisms within the application's user management module. Specifically, the /user/info endpoint is designed to return detailed information about users, including sensitive credentials such as password hashes. However, the implementation fails to redact or mask these cryptographic values before transmitting them over the network. This oversight allows any authenticated user with valid session tokens to query arbitrary user profiles by supplying specific user identifiers in their requests. The resulting response includes unsalted MD5 hash digests for every requested account, exposing a significant portion of the application's credential database to potential compromise.
From a technical perspective, this flaw constitutes an insecure direct object reference combined with improper output handling. By allowing authenticated users to manipulate the user ID parameter without sufficient authorization checks or data filtering, the system exposes sensitive internal state information. The use of MD5 for password hashing further exacerbates the risk, as MD5 is widely considered cryptographically broken and unsuitable for securing passwords due to its speed and susceptibility to rainbow table attacks. Because the hashes are stored without salt, precomputed lookup tables can be used to reverse-engineer plaintext passwords with high efficiency. This lack of salting means that identical passwords across different users result in identical hash values, providing additional clues to attackers attempting to identify common or weak credentials within the system.
The operational impact of this vulnerability is severe, as it facilitates both offline password cracking and potential direct authentication bypasses. Once an attacker obtains a collection of unsalted MD5 hashes, they can employ brute-force or dictionary attacks using readily available tools like Hashcat or John the Ripper to recover plaintext passwords. These recovered credentials may not only grant access to other accounts within jshERP but could also be used for credential stuffing attacks against external services if users have reused passwords across different platforms. Furthermore, in environments where single sign-on or shared authentication mechanisms are present, compromised hashes might allow lateral movement into more critical systems that rely on the same identity provider infrastructure.
This vulnerability aligns with several recognized industry standards and taxonomies. It is classified under CWE-209 as Generation of Error Message Containing Sensitive Information, although it specifically involves the leakage of credential data rather than just error messages. More accurately, it falls under CWE-522 Insufficiently Protected Credentials, which covers cases where authentication credentials are transmitted or stored in a format that is easily reversible by unauthorized actors. In terms of offensive security tactics, this behavior maps to ATT&CK technique T1078 Valid Accounts, as the attacker leverages existing valid accounts to access sensitive information and potentially escalate privileges within the application environment.
Mitigation strategies must address both the immediate exposure and the underlying architectural weaknesses. The most urgent remediation step is to patch the /user/info endpoint to strictly redact or exclude password hashes from all API responses, regardless of the requesting user's role. Additionally, developers should implement robust access control checks to ensure that users can only retrieve information about their own profiles unless explicitly authorized for administrative functions. Beyond fixing the immediate leak, it is imperative to migrate away from MD5 hashing entirely. The system should adopt modern, memory-hard password hashing algorithms such as Argon2 or bcrypt, which include built-in salting mechanisms and are resistant to GPU-accelerated brute-force attacks. Regular security audits and static code analysis tools configured to detect insecure cryptographic practices can help prevent similar vulnerabilities in future development cycles.