Dokan Multivendor EUVD-2026-63819

Exploitation requires a valid vendor account on the target Dokan-powered WooCommerce marketplace - vendor registration is often open to the public on marketplace sites, making this condition easily satisfied by a motivated attacker. The reverse-withdrawal feature must be active and configured on the site (this is a core Dokan feature but must be enabled by the operator). The CVSS PR:H designation reflects that a vendor-level authenticated session is the minimum requirement; unauthenticated or subscriber-level WordPress users cannot exploit this. The limiting factor for most environments is that the attacker must first be an enrolled vendor, which may require operator approval on some marketplace configurations, and exploitation only impacts financial ledger records rather than underlying platform security.

The NVD CVSS 3.1 score of 2.7 (Low) reflects the technical CIA impact correctly - no data is exfiltrated (C:N) and no availability is affected (A:N), with only a Low integrity impact (I:L) on the vulnerability's technical metrics. However, the real-world business impact significantly exceeds what CVSS captures: vendors can commit financial fraud against marketplace operators by eliminating legitimate commission debts, potentially causing direct monetary loss. PR:H correctly reflects that exploitation requires an authenticated vendor account, which limits exposure to registered participants of the marketplace rather than anonymous internet actors. A public proof-of-concept is available per WPScan (EUVD-2026-63819), which lowers the exploitation bar. No EPSS data was provided in the input, and the vulnerability is not in CISA KEV, so widespread opportunistic exploitation is not confirmed. The risk is best characterized as: low severity from an infrastructure perspective but high business risk for any operator running a revenue-generating multivendor marketplace on the affected versions.

A registered vendor on an affected Dokan marketplace logs into their vendor dashboard and submits a crafted HTTP POST request to the reverse-withdrawal payment endpoint, specifying an arbitrary payment amount equal to or exceeding their outstanding commission balance. Because the server does not validate this amount against the actual ledger balance, the system records the payment as legitimate and clears the commission debt. A public proof-of-concept is available, meaning the specific request structure is documented and reproducible with minimal effort.