CVE-2026-81031
Description
IDURAR ERP CRM changes the password of whichever account a request names rather than the account making the request. The update handler in backend/src/controllers/middlewaresControllers/createUserController/updatePassword.js resolves the authenticated user from the request that the token middleware populated, then issues its update against a filter built from the identifier in the URL path, and never compares the two. The route is mounted behind the administrator token check only, so any valid administrator session is sufficient, and the sole ownership-like guard in the handler rejects a single hardcoded demo address. A caller can therefore set an arbitrary password on any other administrator account and sign in as it. The read handler in the same controller directory accepts an identifier the same way, which supplies the identifiers needed to pick a target.
Predictions
Heuristic predictions, AS-IS, for prioritization only.
Mitigations
No mitigations published for this CVE yet.
The vendor-content worker queues fetches as references arrive (check back in a few minutes). Or — if you've already worked around this in production — publish your fix to the community-verified tier.
Propose a mitigation on Community Mitigations published via the community go through AI scoring + 2 human reviewers + 7-day silent objection window before landing here withsource_tier=community-verified.
References
- https://github.com/idurar/idurar-erp-crm
- https://github.com/idurar/idurar-erp-crm/blob/v4.1.0/backend/src/controllers/middlewaresControllers/createUserController/updatePassword.js
- https://github.com/idurar/idurar-erp-crm/issues/1470
- https://www.vulncheck.com/advisories/idurar-erp-crm-through-4.1.1-account-takeover-via-unverified-identifier-on-password-update
CWEs
CWE-639
Community-verified mitigations for this CVE will appear above when contributors publish them.
Verify integrity in audit chain (admin only). AS-IS.