Dokan EUVD-2026-39950

The attacker must hold an authenticated WordPress account at 'custom-level' or above - in the Dokan context this corresponds to a vendor or seller role, which is the standard low-privilege role on a multivendor marketplace. Sites that permit open self-registration of vendor accounts require no additional access beyond account creation. The store search widget must be deployed and active on at least one front-end page, as this is the specific delivery vector for the stored payload via AJAX. The vulnerability is triggered by the victim loading any page containing the store search widget that processes the affected AJAX response; no interaction beyond a page load or search query is required from the victim. Exploitation is limited to the front-end DOM context (no server-side code execution); impact is scoped to what JavaScript can do in a visitor's browser session. Sites without open vendor registration or without the store search widget deployed face a materially reduced attack surface.

The CVSS 3.1 score of 6.4 (Medium) with vector AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N carries several noteworthy signals. The scope change (S:C) elevates real-world impact significantly beyond what the numeric score implies: a successful payload executes in an arbitrary victim's browser, enabling session hijacking, credential phishing overlays, or malicious redirects against any user who visits a search results page. Attack complexity is low and no special preconditions beyond a vendor account are required, meaning exploitation is straightforward once initial access is obtained. The PR:L requirement (a vendor/seller account) is a meaningful but often low barrier on marketplaces with open self-registration - if the target site allows anyone to register as a vendor, the effective barrier to exploitation approaches zero. No EPSS data was provided, no CISA KEV listing exists, and no POC has been confirmed, so automated or opportunistic mass exploitation is not indicated at this time. The risk is highest for marketplace operators who permit unrestricted vendor onboarding and have not yet patched; the risk is substantially reduced for platforms with manual vendor vetting or restrictive account creation workflows.

An attacker registers a vendor account on the target marketplace (or compromises an existing vendor account) and creates or edits a product, inserting a JavaScript payload such as a cookie-stealing script into the Product SKU field. When any site visitor - including unauthenticated users - uses the store search widget, the front-end issues an AJAX request, receives the unescaped SKU in the HTML response, and jQuery's .html() method renders and executes the injected script in the visitor's browser, potentially exfiltrating session tokens or performing actions on the victim's behalf. No public exploit code has been confirmed, but the attack requires no specialized tooling beyond a vendor account and a crafted product listing.