CVE-2026-94412 is a high severity (CVSS 8.8) missing authorization flaw in jshERP through version 3.6. Any authenticated user can reset another user's password, including an administrator's, through the POST /user/resetPwd endpoint. I could not confirm a fixed release, so restrict the route and watch the project.
What's affected
The record says jshERP through 3.6 is affected. The weakness is CWE-862, missing authorization. The record describes the POST /user/resetPwd endpoint accepting a target user ID from an authenticated caller and resetting that account's password to a known default value.
I found no fixed version in the sources I could read. The references are the project repository, the controller source at v3.6 and the VulnCheck advisory, none of which names a patched release.
One point where scores differ. The record gives CVSS 8.8 from a version 3.1 vector. VulnCheck's advisory lists severity high with a CVSS version 4 score of 8.7. Both put it in the high band.
How to check if you're exposed
Find out which jshERP release you run and compare it with 3.6.
Then check whether the reset route is exposed. If you run a reverse proxy, search its logs for calls to the endpoint.
grep "/user/resetPwd" /var/log/nginx/access.log
Calls you cannot tie to an administrator action deserve a closer look. Also look at your user table for accounts whose passwords were recently changed, especially administrators.
What to do now
- Check the jshERP repository for a release after 3.6 that fixes the endpoint, and apply it when available.
- Until then, block or restrict POST /user/resetPwd at your reverse proxy so only trusted administrator addresses can reach it.
- Reset administrator passwords if you see unexplained calls to the endpoint, and review recent logins.
- Do not leave jshERP reachable from the public internet. Put it behind a VPN or an allowlist.
- Review default passwords: the record says the reset sets a known default value, so change any account still on a default.
Why it matters
Authorization checks answer a different question than login checks. Here the application knows who the caller is, but does not check whether that caller is allowed to act on the target account. CWE-862 bugs of this kind turn any low privilege account into an account takeover tool.
In an ERP system the accounts guard financial and inventory records. The record does not mark exploitation, and the CVE is not in CISA's catalog. A public proof of concept exists in the references, which raises the chance of copycat use, so do not wait for a release to apply the proxy rule.
Quick check
Do attackers need valid credentials?
Yes, any authenticated account. The flaw is that the endpoint does not check whether that account may reset someone else's password.
Is there a patch?
I could not confirm one. Check the project repository and apply a proxy restriction in the meantime.
Sources
Last reviewed: 18 October 2026.
