CVE-2026-12077 · Dokan Pro WordPress plugin — unauthenticated time-based SQL…

01 · The Real Story

A coupon-code field that hands attackers a query console into your customer database

Dokan Pro is the paid extension to Dokan, a multi-vendor marketplace plugin layered on WooCommerce — think Etsy-in-a-box for WordPress. The store-locator feature accepts latitude and longitude parameters that are concatenated into a SQL query without parameterization or escaping, so an unauthenticated visitor can append a SLEEP() or boolean payload and exfiltrate database contents one timing bit at a time. All versions through 5.0.4 are affected; the bug touches the geo-search endpoint that the storefront itself calls, so it is reachable on any public marketplace install.

Vendor severity of HIGH (7.5) is fair. The CVSS vector is AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N — no auth, no user interaction, full confidentiality impact, but no integrity or availability. That matches a read-only SQLi: attackers can dump wp_users (including hashed passwords and session tokens that often *do* yield write access via password reset), order PII, and any custom marketplace tables, but they cannot directly write rows or drop the DB. The data-exfil ceiling is what keeps this off CRITICAL.

"Unauthenticated time-based SQLi in a popular WooCommerce marketplace plugin — internet-facing by design, mass-scan bait by Friday."

02 · The Attack Path

4 steps from start to impact.

STEP 01

Locate Dokan Pro marketplace installs

Attacker queries Shodan/FOFA/PublicWWW for dokan-pro asset paths, the Dokan store-listing shortcode markup, or the /dokan/ REST namespace. Wordfence/Patchstack public disclosure on 2026-06-24 will trigger commodity scanning within 24–72 hours.

Conditions required:

WordPress site with Dokan Pro plugin active
Public HTTP(S) reachability

Where this breaks in practice:

None — marketplaces are by definition public-facing

Detection/coverage: Shodan favicon hash and HTML fingerprints exist for Dokan; Wordfence WAF signatures land within days of disclosure

STEP 02

Probe the latitude/longitude geo-search endpoint

Attacker fires a baseline request to the vendor/store-locator endpoint and observes response time, then injects a latitude=0) AND SLEEP(5)-- - style payload. A consistent ~5s delay confirms time-based blind SQLi. sqlmap -u '<url>' -p latitude --technique=T --dbms=mysql automates the rest.

Conditions required:

Endpoint reachable without auth
Database thread allows SLEEP() — default in MySQL/MariaDB

Where this breaks in practice:

WAF (Cloudflare, Wordfence, Patchstack mu-plugin) may block obvious SLEEP payloads
Aggressive rate limiting slows time-based extraction

Detection/coverage: Wordfence and Patchstack mu-plugin both publish virtual patches within 24h of Wordfence-disclosed plugin CVEs

STEP 03

Enumerate schema and dump credentials

sqlmap walks information_schema to identify wp_users, wp_usermeta, wp_dokan_*, and wp_woocommerce_* tables, then extracts user_login, user_pass (phpass/bcrypt), user_email, and order PII. Time-based blind on a single thread typically yields a full user table in 30–120 minutes against a healthy site.

Conditions required:

Step 2 succeeded
DB user has SELECT on wp_* tables — always true, WordPress runs as a single DB user

Where this breaks in practice:

WAF anomaly detection on long-running parametric requests
Connection limits on shared hosting

Detection/coverage: Sustained low-and-slow GET pattern to one endpoint is visible in access logs and most CDN analytics

STEP 04

Pivot from exfiltrated data to account takeover

Crack phpass hashes offline (hashcat mode 400) or hijack admin sessions via stolen wp_usermeta session tokens. Once an admin account is owned, the attacker uploads a malicious plugin/theme for RCE — converting the read-only SQLi into full site control. This is the standard WordPress SQLi → RCE chain.

Conditions required:

Hashes crackable OR session tokens still valid
Admin login not gated by MFA / IP allowlist

Where this breaks in practice:

WordPress MFA plugins (WP 2FA, miniOrange) defeat token replay for admins
Strong unique admin password defeats hashcat in any reasonable window

Detection/coverage: New plugin install / theme edit events are logged by Wordfence, Sucuri, and audit-log plugins

03 · Compensating Control

Deploy WAF rule blocking SQL keywords in latitude / longitude parameters — Cloudflare, AWS WAF, Wordfence Premium, and Patchstack publish virtual patches for Wordfence-disclosed plugin CVEs within 24–48h. Add a custom rule blocking (SLEEP|BENCHMARK|UNION|SELECT|--|;) patterns in those two parameters now and let the managed rule replace it. Per the noisgate mitigation SLA for HIGH, get this in place within 30 days — ideally within the week given the unauth posture.

Disable the Dokan Pro store-locator / geo-search feature if not in use — Many marketplaces enable the geo module by default but do not advertise it on the storefront. Disable in Dokan → Settings → Modules if unused, eliminating the vulnerable code path entirely until patched.

Enforce MFA on all WordPress administrator and shop_manager roles — Cuts the SQLi-to-RCE pivot at step 4. Use WP 2FA, miniOrange, or your SSO provider's WordPress connector. This is permanent hygiene, not a tactical mitigation.

Rotate all WordPress admin and DB-user passwords post-exploit-window — If you cannot confirm the site was not probed between 2026-06-24 and patch-apply, treat admin password hashes and wp_usermeta session tokens as potentially leaked. Force-logout all users and rotate.

Subscribe to Wordfence + Patchstack advisories for the patched version — Vendor fix is not enumerated in the initial Wordfence advisory; monitor Wordfence Threat Intel and the Dokan changelog and apply the moment a patched build ships.

What doesn't work

Cloudflare's *default* WAF managed rules — generic SQLi signatures catch obvious UNION SELECT but routinely miss time-based blind payloads encoded with comments and case variation. Use the parameter-specific custom rule above.
Database least-privilege — WordPress runs as a single DB user with full SELECT on wp_* tables. There is no row-level access control to leverage.
Network segmentation / IP allowlisting — defeats the purpose of a public marketplace; cannot be applied to the storefront.
WordPress core hardening (DISALLOW_FILE_EDIT, DISALLOW_FILE_MODS) — useful for limiting step-4 RCE pivot, but does nothing for the SQLi itself.

04 · Intelligence Metadata

The supporting signals.

CVE	CVE-2026-12077
CWE	CWE-89 (SQL Injection)
Vendor CVSS	7.5 HIGH — `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N` (unauth, network, confidentiality-only)
EPSS	0.00273 (~0.3%) — low today, expect a 10x bump within 30 days as Wordfence-disclosed plugin CVEs are routinely weaponized
KEV	Not listed (as of 2026-06-30)
Affected versions	Dokan Pro ≤ 5.0.4 (all versions through current at disclosure)
Fixed version	Not yet published in the advisory — track Dokan changelog and Wordfence advisory for the patched build
PoC availability	No public PoC in GitHub/Exploit-DB at disclosure, but trivially reproducible with `sqlmap --technique=T` against the geo endpoint
In-the-wild	No confirmed mass exploitation yet; historical baseline for unauth Wordfence-disclosed plugin SQLi shows scanning within 72h of advisory
Researcher	Le Quoc Bao of Noventiq RedTeam (via Wordfence CNA)
Disclosed	2026-06-24 (Wordfence advisory) / 2026-06-25 (NVD)
Install base	Dokan family ~50k active installs (free); Pro install count is private but estimated low-thousands of paying marketplaces — every one is internet-facing

Sources.

05 · The Call

Final Verdict

= UNCHANGED to HIGH (7.8/10)

Why this verdict

Zero auth friction: the endpoint is reachable by anonymous storefront visitors — there is no 'requires internal access' downgrade available here.
Internet-facing by design: a marketplace plugin has no realistic deployment behind a VPN; exposed-population is ~100% of installs, unlike enterprise admin panels.
Role multiplier: Dokan Pro is a *line-of-business e-commerce app* (typical role), not a domain controller, hypervisor, IdP, or CI/CD system. Blast radius is tenant-bounded to one WordPress DB → PII + hashed creds + orders. No fleet pivot, no supply-chain reach. Floor stays at HIGH, not CRITICAL.
Confidentiality-only impact: CVSS vector is C:H/I:N/A:N — read-only SQLi, no direct row writes or DROP. The integrity escalation requires a second step (hash cracking or session replay) that MFA and strong passwords break.
Time-based blind slows but does not stop exploitation: sqlmap handles it natively; the speed cost is hours, not days, and is irrelevant to a determined attacker.
Wordfence-disclosed plugin SQLi has a reliable weaponization timeline: commodity scanning within 72h, mass exploitation campaigns within 2–4 weeks. EPSS of 0.27% reflects *today*, not the trajectory.

Why not higher?

CRITICAL is reserved for chains that end in RCE, fleet compromise, or supply-chain pivot without a second exploitation step. This bug is confidentiality-only at the CVSS layer; the escalation to admin takeover depends on weak passwords or absent MFA — those are additional prerequisites that meaningfully reduce real-world worst-case outcomes. The component is also not a high-value-role asset (no IdP, hypervisor, or CA blast radius).

Why not lower?

MEDIUM is wrong because it implies a meaningful prerequisite — auth, user interaction, internal network, narrow version range — and none apply. The vuln is unauth, default-config, current-version, and public-facing. Downgrading would tell defenders to deprioritize a chain that any script-kiddie with sqlmap can run against any Dokan Pro site on the internet.

06 · Verification

Crowdsourced verification payload.

Run from any auditor workstation that can reach the target site over HTTPS. No credentials required (this checks plugin presence and version via the public readme.txt). Invoke as: ./check-dokan.sh https://marketplace.example.com. Exits 1 = VULNERABLE, 0 = PATCHED/NOT-PRESENT, 2 = UNKNOWN.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash
# noisgate verifier — CVE-2026-12077 Dokan Pro SQLi
# Usage: ./check-dokan.sh https://target-site.tld
set -u

TARGET="${1:-}"
if [[ -z "$TARGET" ]]; then
  echo "Usage: $0 https://target-site.tld" >&2
  exit 2
fi

VULN_CEILING="5.0.4"   # all versions <= this are vulnerable per advisory
UA="noisgate-verifier/1.0 (+cve-2026-12077)"

# 1. Try the canonical plugin readme path
README_URL="${TARGET%/}/wp-content/plugins/dokan-pro/readme.txt"
BODY=$(curl -fsSL -A "$UA" --max-time 15 "$README_URL" 2>/dev/null || true)

if [[ -z "$BODY" ]]; then
  # 2. Fallback: look for Dokan fingerprint on the homepage
  HOME=$(curl -fsSL -A "$UA" --max-time 15 "$TARGET" 2>/dev/null || true)
  if ! echo "$HOME" | grep -qiE 'dokan|wedevs'; then
    echo "PATCHED: Dokan Pro not detected on $TARGET"
    exit 0
  fi
  echo "UNKNOWN: Dokan fingerprint present but version unreadable (readme blocked)"
  exit 2
fi

VERSION=$(echo "$BODY" | grep -iE '^Stable tag:' | head -1 | awk -F: '{print $2}' | tr -d ' \r')
if [[ -z "$VERSION" ]]; then
  echo "UNKNOWN: readme found but Stable tag missing"
  exit 2
fi

# Semver compare: vulnerable if VERSION <= VULN_CEILING
lowest=$(printf '%s\n%s\n' "$VERSION" "$VULN_CEILING" | sort -V | head -1)
if [[ "$lowest" == "$VERSION" ]]; then
  echo "VULNERABLE: Dokan Pro $VERSION <= $VULN_CEILING (CVE-2026-12077)"
  exit 1
else
  echo "PATCHED: Dokan Pro $VERSION > $VULN_CEILING"
  exit 0
fi