Dokan EUVD-2026-102619

Two concrete prerequisites must both hold: (1) the attacker must possess a Dokan vendor/custom-level account - attainable without approval via the public 'I am a vendor' self-registration flow only when that option is enabled on the site; and (2) the target must be a customer who has placed at least one order with the attacking vendor, since the object-level guard permits edits only on that vendor's own customers. Exploitation is further limited to Dokan versions up to and including 5.2.1, requires authentication (PR:L), and does not require user interaction. Sites that disable open vendor registration or vet vendors manually substantially raise the bar, as the attacker must otherwise obtain vendor access by other means.

This is a genuine but bounded authorization flaw (CWE-639 IDOR), not a high-urgency emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N, 4.3 Medium) is internally consistent with the description: network-reachable REST endpoint, low complexity, but requiring PR:L - a vendor/custom-level account. No EPSS score was supplied in the input, so exploitation probability cannot be quantified here. The CVE is NOT in CISA KEV and there is no public exploit identified at time of analysis, so this is 'no public exploit identified' rather than active exploitation. Two factors raise concern above the raw score: (1) the required vendor privilege is self-granting via the public 'I am a vendor' registration flow when enabled, effectively collapsing PR:L toward attacker-attainable; (2) the outcome is account takeover, which arguably carries a confidentiality impact the vendor's C:N does not capture (logging in as the victim exposes their PII and order history). Countering that, exploitation is scoped: the attacker can only reset the password of a customer who has already placed at least one order with that specific attacking vendor, limiting it to targeted rather than mass takeover. Net: a legitimate patch-worthy issue for live marketplaces, prioritized Medium.

An attacker self-registers as a vendor on a Dokan marketplace that permits open vendor signup, then waits for (or solicits) a customer to place an order with their store. Using the authenticated Dokan REST customers endpoint, the vendor sends an update request carrying a 'password' value for that customer's user ID, which is accepted due to missing validation on the user-controlled key, and then logs in as the victim. No public proof-of-concept is identified at time of analysis; exploitation is network-based and low-complexity but requires the pre-existing vendor-customer order relationship.