CVE-2026-109186 in jshERP
Summary
by MITRE • 10/12/2026
jshERP through 3.6 contains a mass assignment vulnerability in the UserController update handler that allows authenticated users to overwrite protected fields including tenant_id and password. Attackers can send a crafted PUT /user/update body to switch into another tenant on next login or overwrite other users' password hashes for account takeover.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/12/2026
The jshERP software, specifically through version 3.6, contains a critical mass assignment vulnerability within the UserController update handler that fundamentally compromises the integrity of user authentication and multi-tenant isolation mechanisms. This flaw arises from improper validation of input parameters during the processing of HTTP PUT requests directed at the /user/update endpoint. In secure application design, frameworks should strictly whitelist allowed fields for updates to prevent clients from modifying internal or protected attributes. However, in this implementation, the backend logic blindly maps incoming JSON payload properties directly onto the user model object without sufficient filtering. This lack of strict input validation allows authenticated users to inject arbitrary data into sensitive database columns that are typically restricted by application-level business logic and security policies.
The operational impact of this vulnerability is severe as it enables two distinct but related attack vectors: tenant impersonation and account takeover. By manipulating the request body, an attacker can overwrite the tenant_id field associated with their user profile. Since jshERP relies on multi-tenancy to isolate data between different organizations or departments within a single deployment instance, altering this identifier effectively shifts the context of the authenticated session. Upon subsequent login attempts or API interactions, the system treats the attacker as if they belong to the targeted tenant, granting them unauthorized access to sensitive business data, financial records, and operational metrics belonging to that specific organization. This breach violates the core principle of multi-tenant isolation, leading to significant confidentiality losses for affected enterprises.
Furthermore, the vulnerability allows attackers to overwrite password hashes by submitting a crafted payload containing a new hashed value in the password field. Since the update handler does not verify whether the user is authorized to change their own credentials or if the input conforms to expected hashing algorithms, an attacker can directly inject a pre-computed hash corresponding to any desired plaintext password. This capability facilitates immediate account takeover for other users within the same tenant or across tenants if the system architecture permits cross-tenant ID manipulation without proper boundary checks. Once the password hash is replaced, the attacker gains full administrative control over the compromised accounts, potentially escalating privileges further depending on the roles assigned to those user profiles.
From a classification perspective, this vulnerability aligns with CWE-284: Improper Access Control and CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes, commonly known as mass assignment or insecure direct object reference in broader contexts. The exploitation technique maps directly to the MITRE ATT&CK framework under T1078: Valid Accounts, specifically leveraging legitimate credentials to escalate privileges or move laterally within a multi-tenant environment by manipulating identity attributes. It also touches upon T1531: Account Access Removal if used maliciously to lock out victims, though the primary threat here is unauthorized access and data exfiltration via tenant switching.
Mitigation strategies must focus on implementing strict allow-listing for all update operations within the UserController. Developers should configure the ORM or serialization layer to explicitly define which fields are mutable by end-users versus those that are system-managed only. Additionally, enforcing server-side validation of the tenant_id field against the session context is crucial; a user’s active session must always be bound to their original assigned tenant regardless of input data. Password changes should require verification of the current password before allowing updates to the hash field, ensuring that only legitimate users with knowledge of existing credentials can modify them. Regular security audits and static code analysis tools configured to detect mass assignment patterns are recommended to prevent similar flaws in future releases or related modules within the jshERP ecosystem.