This vulnerability allows any authenticated vendor account in a Dokan multivendor marketplace to reset the password of any user on the WordPress installation—including administrator accounts—through a single PUT request to the /dokan/v1/customers/{id} endpoint. The attack works because Dokan's REST controller validates only that the requesting user holds the vendor role, then proceeds to perform password operations on the target user without any ownership or permission check.
The critical point isn't that a security check was forgotten—it's that Dokan registered its own REST routes under /dokan/v1/ that duplicate WooCommerce's customer management functionality, but replaced WooCommerce's manage_woocommerce capability gate with a simple vendor-role validation. This creates a parallel API surface with weaker security controls living alongside WooCommerce's existing, properly-protected endpoints. The secure routes still exist at /wc/v3/customers; they're just no longer the dominant path for Dokan-specific operations.
For defenders, the priority is immediate: restrict vendor role provisioning to trusted users, audit existing vendor accounts for signs of compromise, and apply the vendor patch as soon as it is available. Beyond patching, treat this as a pattern failure rather than an isolated bug. Dokan likely implements similar architectural overrides in other REST controllers, so a full audit of their API surface is warranted. Detection is complicated because security scanners focused on WooCommerce endpoints won't flag /dokan/v1/ routes—this lives in plugin-specific namespace space.
The 8.8 CVSS may actually understate operational risk because it doesn't capture how easily vendor accounts can be obtained in typical multivendor deployments, or the mass PII exfiltration risk from the GET endpoint that allows any vendor to query all user records across the entire installation, including customers unrelated to their storefront.