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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.2",
  "pubDate": "2026-08-26T16:16:45.860Z",
  "pubdate": "2026-08-26T16:16:45.860Z",
  "executiveSummary": "The IDURAR ERP CRM application is affected by an Improper Authorization vulnerability within its user management module.\nThis vulnerability allows an authenticated administrator to modify the password of any other account within the system, including other administrator accounts, due to a failure in validating the identity of the user requesting the password change against the target identifier.\nThe vulnerability resides in the update handler responsible for password changes, which improperly trusts the identifier provided in the URL path rather than enforcing authorization checks based on the authenticated session token.\nAn attacker with valid administrator credentials can leverage this flaw to perform unauthorized account takeovers, potentially leading to full system compromise, data exfiltration, or total loss of integrity.\nThe exploitation is straightforward and requires an active session with administrative privileges. The lack of proper ownership validation or identity verification in the backend logic facilitates this privilege escalation path.",
  "technicalDetails": "The vulnerability is located in the password update logic, specifically within backend/src/controllers/middlewaresControllers/createUserController/updatePassword.js. The root cause of the flaw is an authorization bypass resulting from insecure object reference and a failure to enforce multi-tenancy or ownership constraints during state-changing operations.\nWhen an administrator initiates a password update request, the token middleware correctly populates the request context with the authenticated user's identity. However, the updatePassword.js handler ignores the identity context derived from the token and instead constructs an update filter based solely on the identifier provided in the URL path.\nThe handler fails to compare the authenticated user identity with the subject of the requested update. Furthermore, the existing security logic includes an insufficient guard mechanism that only rejects requests targeting a single hardcoded demo account, leaving all other system accounts, including high-privilege administrators, vulnerable to unauthorized modification.\nThe exploitation flow is as follows: 1) An attacker authenticates as a legitimate administrator to obtain a valid session token. 2) The attacker utilizes the read handler within the same controller directory to enumerate valid account identifiers. 3) The attacker crafts a request to the updatePassword.js endpoint, providing the identifier of a target account (e.g., another admin or a service account) in the URL path. 4) The server processes the request, updates the password for the target account specified in the path, and returns a successful response. 5) The attacker then authenticates as the victim account using the newly set password, achieving full account takeover.\nBecause the route is protected only by a generic administrator token check, any session with administrative privileges is sufficient to trigger this vulnerability. This bypass effectively allows for arbitrary password resets, granting the attacker the ability to escalate privileges, hijack existing sessions, or maintain persistence within the application environment. The impact is critical, as it bypasses intended access control models and allows for lateral movement and complete administrative compromise across the entire ERP deployment."
}