CVE-2026-109186 is a high severity mass assignment flaw (CVSS 8.8) in jshERP through version 3.6. An authenticated user can overwrite protected fields, including the tenant id and password, which can lead to switching tenants or taking over accounts. The record names no fixed version.
What's affected
The record says jshERP through 3.6 is affected, and VulnCheck's advisory, which we fetched, says jshERP up to and including 3.6. Neither names a fixed version, so the project repository is where to look for a release after 3.6.
The weakness is CWE-915, improperly controlled modification of dynamically determined object attributes, the formal name for mass assignment. The record's vector is network reachable, low complexity, low privileges, no user interaction, and high impact on confidentiality, integrity and availability.
A difference in scoring: the record gives CVSS 3.1 8.8, while VulnCheck gives a CVSS 4.0 score of 8.7. These are different versions of the scoring system and both say high.
The update handler for users is the entry point. The record describes a crafted request body to the user update endpoint that can switch a user into another tenant at next login, or overwrite other users' password hashes. For a multi tenant ERP, tenant separation is the main security promise, so this reaches the core of the product.
How to check if you're exposed
Identify whether you run jshERP and which version, and compare it with 3.6.
Then consider who has an account. The record needs an authenticated user, but in an ERP that covers every employee, partner and customer user in every tenant. List the accounts and the tenants and ask which of them you would trust with another tenant's data.
Review the audit trail for changes to user records: look at the database for users whose tenant id changed or whose password hash changed without a reset request. If your database keeps timestamps on user rows, query for recent modifications and compare them with your help desk records.
Finally, look at the web server or proxy logs for calls to the user update endpoint from accounts that do not hold administrator rights.
What to do now
- Watch the jshERP repository for a release after 3.6 and upgrade when it appears.
- Until then, limit access to the application to trusted networks or a VPN, because any account holder can reach the flaw.
- Review user records for unexpected tenant or password changes and force password resets for accounts that look touched.
- Add a proxy rule that blocks the user update call for non administrator roles, if your deployment allows it.
- If you maintain the code, bind update requests to an explicit allowlist of fields instead of copying the whole request body onto the user object.
Why it matters
Mass assignment happens when a framework copies every field in an incoming request onto an object. If the object has sensitive fields such as the tenant or the password hash, a caller who adds those fields to the request can set them, even though the form never offered them.
The fix is not complicated. A handler should take only the fields it expects, which is usually a short list, and ignore the rest. Many frameworks offer an allowlist feature for this purpose. The mistake survives because the happy path works, and nobody tests with an extra field.
The consequences here are the worst kind for a business system. Crossing tenants breaks separation of customers, and overwriting another user's password hash is account takeover, without needing their password. The record does not mark this CVE as known exploited, but with no patch noted, exposure management matters.
Quick check
Is there a fix?
The record and VulnCheck name no fixed version. Watch the project repository.
Do I need an account to exploit it?
Yes, the record says authenticated users. In an ERP, that can still be a large group.
Sources
You can also run a free in-browser dependency scan at gold.safeguard.sh/scan to see which of your packages carry known CVEs.
Last reviewed: 18 October 2026.
