Dokan Pro EUVD-2026-39166

Exploitation requires sending requests to the Dokan Pro request handler that processes the 'latitude' and 'longitude' parameters (the vendor/store geolocation functionality) on a site running Dokan Pro 5.0.4 or earlier. Per the CVSS vector (PR:N/UI:N), no authentication and no user interaction are required, and the affected endpoint must be reachable from the network - i.e. exploitation works against a default internet-facing installation as long as the geolocation code path is present. The primary limiting factor is that the injection is time-based blind, so data extraction is slow and dependent on observing response timing; deployments that disable or do not expose the geolocation feature, or that filter the latitude/longitude parameters at a WAF, materially reduce exposure.

The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, base 7.5) describes a network-reachable, low-complexity, unauthenticated injection with high confidentiality impact but no integrity or availability impact - consistent with a read-only/data-exfiltration SQL injection. These signals align coherently with the description, so there is no internal conflict. The blind/time-based nature raises practical exploitation effort and slows mass automated extraction, somewhat tempering the otherwise-high CVSS. No EPSS probability, SSVC decision, KEV status, or POC indicator was supplied, so real-world exploitation likelihood cannot be quantified from the input; the absence of these is a data gap, not evidence of low risk. Given SQL injection is highly automatable and the plugin is internet-facing on e-commerce sites holding customer PII, this should be treated as a genuine high-priority patching item rather than a high-CVSS-but-low-impact theoretical issue.

An unauthenticated attacker sends crafted HTTP requests to the public Dokan Pro endpoint that accepts 'latitude' and 'longitude', appending a time-based blind SQL injection payload (e.g. a conditional SLEEP) to the existing query. By observing response delays, the attacker iteratively extracts WordPress user password hashes, secret keys, and customer order data from the database. No public POC is referenced in the source data, but the low complexity and lack of authentication make exploitation straightforward to automate.