IDURAR ERP CRM EUVD-2026-66607

A valid administrator session token is required - the route is mounted exclusively behind the administrator token middleware (PR:H per CVSS 4.0), so unauthenticated access and access by non-administrator roles are not possible. No additional configuration, special feature flag, or non-default deployment mode is required; the vulnerability exists in the default password-update flow for every administrator account. The only in-code guard is a hardcoded rejection of a single demo email address, which does not protect production accounts. Exploitation is limited to targets running IDURAR ERP CRM through v4.1.1 and is further constrained to deployments where the backend API is network-accessible to the attacker. Single-administrator deployments have no peer accounts to target and are not exposed to cross-account takeover from this flaw alone.

The CVSS 4.0 vector AV:N/AC:L/AT:N/PR:H/UI:N scores 8.6 (High), with PR:H as the primary limiting factor. In practice, the PR:H requirement means exploitation is constrained to actors who already hold a valid administrator credential - unauthenticated and low-privilege attackers cannot reach this endpoint. However, in any multi-administrator deployment, a single compromised or malicious administrator can silently take over all peer administrator accounts, making this a meaningful lateral-privilege-escalation and account-takeover risk within that threat model. EPSS data is absent from the provided intelligence, so exploitation probability cannot be quantified numerically. KEV status is not confirmed, and no public exploit code has been identified. The flaw is nonetheless straightforwardly exploitable - low complexity, no race condition - so the gap between CVSS severity and real-world risk is not large here. The primary mitigating factor is the administrator-only attack surface; organizations with strictly one administrator account per deployment are not exposed to cross-account takeover.

An attacker holding a compromised administrator account issues a GET request to the read handler, supplying account identifiers in the URL path to enumerate other active administrator accounts and retrieve their internal IDs. The attacker then sends a PATCH or PUT password-update request to the update endpoint with a targeted administrator's ID in the URL path and a known replacement password; the backend validates only that the caller presents a valid administrator token and updates the target account's password without verifying ownership. The attacker immediately authenticates as the hijacked administrator, gaining full platform access under that identity.