jshERP EUVD-2026-97390

Exploitation requires the attacker to already hold a valid authenticated jshERP account (PR:L) capable of calling the PUT /user/update endpoint; no user interaction or non-default configuration is needed, and the flaw is present in the default UserController update handler through version 3.6. The specific prerequisite is the ability to submit an update request whose body includes the protected tenant_id and password fields, which the handler binds without a server-side allowlist. Limiting factors: the attacker must first obtain or register a low-privilege account (so purely unauthenticated attackers are excluded), and impact scope depends on the deployment being multi-tenant and having other user accounts worth taking over.

This is a credible, actionable priority rather than a high-CVSS-but-low-real-risk issue. The supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) describes network-reachable exploitation with low complexity, no special attack requirements, and only low privileges - meaning any authenticated user (any tenant account) can trigger it, which matches the description's 'authenticated users' and the mass-assignment nature (CWE-915). A publicly available POC exists (github-poc reference), raising practical exploitability, though the CVE is NOT in CISA KEV and no EPSS score was provided in the input, so there is no evidence of widespread or confirmed active exploitation yet - the POC signal and the KEV/EPSS signals should not be conflated. The impact triad VC:H/VI:H/VA:H is consistent with the description: overwriting password hashes enables full account takeover (integrity/availability for the victim) and tenant_id manipulation enables cross-tenant access (confidentiality). The one notable signal conflict is the 'Information Disclosure' tag, which understates the vulnerability - the dominant impact is integrity/privilege (account takeover and tenant switching), not merely disclosure. Net assessment: real priority for any organization running jshERP with multiple user accounts, tempered by the fact that the attacker must first hold a valid low-privilege account and that real-world deployment footprint is limited.

An attacker who holds any low-privileged jshERP account (self-registered or a compromised standard user) sends a crafted PUT /user/update request that includes the protected tenant_id and password fields in the body. Because the update handler binds request parameters directly to the user entity (mass assignment), the attacker overwrites another user's password hash to seize that account, or changes their own tenant_id to pivot into a different tenant on next login. A public POC (poc_identity_privilege_write.py) demonstrates this write primitive.