CVE-2024-3922

What it actually does

The described flaw is an unauthenticated SQL injection in the Dokan Pro WordPress plugin through the user-controlled `code` parameter in versions up to and including 3.10.3. Because the parameter is not safely escaped or bound with prepared statements before being used in a SQL query, an attacker can alter the intended database query. Depending on database permissions and application behavior, this can allow extraction of sensitive database content, authentication data, order/customer information, and potentially database modification or denial of service. The supplied affected-product metadata references `micronaut-projects/micronaut-core (GIT)` with fixed commit `68f9bb0a78fa930865d37fca39252b9ec66e4a43`, which is inconsistent with the WordPress plugin description and should be validated against the authoritative advisory before remediation scoping.

Why it matters to the business

A successful attack can expose customer, vendor, order, and user-account data from an affected WordPress marketplace site and may enable account takeover or site manipulation if database writes are possible. The issue is critical, remotely exploitable without authentication, has weaponized exploit maturity, and has a high EPSS value, meaning internet-facing vulnerable sites should be treated as likely targets even though it is not currently listed in CISA KEV or marked as ransomware-used. Because the issue has been public for a long time, unpatched systems may already have been scanned or exploited.

How an attack unfolds

An attacker first identifies a WordPress site running a vulnerable Dokan Pro version. They then send crafted HTTP requests to the plugin functionality that accepts the `code` parameter. Instead of supplying a normal code value, the attacker appends SQL syntax such as quote-breaking payloads, boolean conditions, UNION-based selection, or time-delay expressions. The vulnerable server incorporates that input into an SQL statement without sufficient parameterization, causing the database to execute attacker-influenced SQL. The attacker can use response differences, returned rows, errors, or timing behavior to confirm injection, enumerate database structure, and extract sensitive rows such as WordPress users, password hashes, emails, customer records, vendor records, orders, and configuration values. If the database account has excessive privileges or stacked queries are possible, the attacker may attempt to alter data, create or modify administrator accounts, plant persistent access through WordPress options or plugin/theme content, or disrupt the database.

How to fix it

Upgrade Dokan Pro to a fixed vendor release newer than 3.10.3, or apply the vendor patch that replaces unsafe SQL construction with prepared statements and strict input validation for the `code` parameter. If using source or dependency tracking, verify the advisory mapping: the provided fixed-version metadata lists `micronaut-projects/micronaut-core (GIT)` fixed in commit `68f9bb0a78fa930865d37fca39252b9ec66e4a43`, but that does not align with the Dokan Pro WordPress plugin description. Until patched, restrict access to vulnerable plugin endpoints where feasible, deploy WAF rules blocking SQL metacharacters and SQL keywords in the `code` parameter, disable the affected plugin if business impact allows, and ensure the WordPress database user has least-privilege permissions and cannot write files or perform administrative database operations unnecessarily. Rotate credentials and invalidate sessions if exploitation is suspected.

How to confirm the fix worked

Confirm the installed Dokan Pro version is newer than 3.10.3 or that the vendor patch is present. Review plugin source or vendor release notes to verify the vulnerable query now uses parameterized database calls rather than string-concatenated user input. From an external perspective, verify that requests containing quote characters, UNION queries, boolean probes, and time-delay payloads in the `code` parameter are rejected, normalized, or handled without SQL errors or timing differences. Validate that WAF or reverse-proxy rules log and block suspicious `code` parameter values. Also verify the asset inventory and SBOM mapping because the supplied affected product/fixed commit metadata conflicts with the vulnerability description.

Typical attack path

1. Discover WordPress sites running Dokan Pro or marketplace-related endpoints.
2. Fingerprint plugin presence and version using page content, static assets, plugin paths, changelog exposure, or vulnerability scanners.
3. Send unauthenticated requests containing crafted SQL syntax in the `code` parameter.
4. Confirm exploitability using SQL errors, boolean response differences, or time-based delays such as `SLEEP()` or `BENCHMARK()`.
5. Enumerate database metadata such as table names, column names, database version, and current user privileges.
6. Extract sensitive WordPress and commerce data, including users, password hashes, customer/vendor information, orders, and configuration secrets.
7. Attempt follow-on actions such as password cracking, account takeover, administrator creation, data tampering, web shell placement through writable application features, or extortion based on stolen data.

How to detect it

Review HTTP access logs, WAF/CDN logs, WordPress application logs, PHP error logs, and database logs for requests containing suspicious SQL syntax in a `code` query or form parameter. Prioritize unauthenticated requests, unusual user agents, high request rates, HTTP 500 responses, database error messages, and requests that produce long response times consistent with time-based SQL injection. Search for SQL keywords and metacharacters such as single quotes, comments, UNION SELECT, INFORMATION_SCHEMA, SLEEP, BENCHMARK, OR 1=1, and hex-encoded or URL-encoded equivalents near `code=`. In database logs, look for unexpected SELECTs against WordPress user tables, options, order/customer/vendor tables, metadata enumeration, or timing functions. For post-exploitation review, examine newly created WordPress administrator accounts, unexpected password or email changes, modified plugin/theme files, suspicious uploads, altered WordPress options, new scheduled tasks, and outbound data transfer anomalies. If a WAF blocked probes but the site remained vulnerable, continue reviewing origin logs because attackers may have bypassed edge controls.

• code='
• code=%27
• code=%22
• code=')
• code=%27)
• code=1%20OR%201=1
• code=%27%20OR%20%271%27=%271
• code=" OR "1"="1
• code=%22%20OR%20%221%22=%221
• code=UNION%20SELECT
• code=%27%20UNION%20SELECT
• code=union+select
• code=information_schema
• code=INFORMATION_SCHEMA
• code=sleep(
• code=SLEEP(
• code=benchmark(
• code=BENCHMARK(
• code=@@version
• code=database()
• code=user()
• code=concat(
• code=group_concat(
• code=load_file(
• code=into%20outfile
• code=--
• code=%2D%2D
• code=%23
• You have an error in your SQL syntax
• Warning: mysqli
• WordPress database error
• SELECT * FROM wp_users
• FROM information_schema.tables
• FROM information_schema.columns

What your security team should do

• Treat internet-facing affected WordPress sites as urgent remediation candidates due to unauthenticated remote exploitability, critical severity, high EPSS, and weaponized exploit maturity.
• Patch or disable Dokan Pro on all affected sites; prioritize versions up to and including 3.10.3.
• Validate vulnerability-management records because the provided package metadata references Micronaut rather than Dokan Pro; correct any asset or SBOM mapping errors before closing remediation.
• Deploy temporary WAF detections and blocks for SQL injection payloads targeting the `code` parameter while patching is underway.
• Search web, WAF, CDN, application, and database logs for historical exploitation attempts since the publication date and especially recent scanning spikes.
• Review WordPress administrator accounts, plugin/theme files, scheduled tasks, and database changes for unauthorized modifications.
• Rotate WordPress administrator passwords, database credentials, API keys, and salts if exploitation is confirmed or sensitive data exposure cannot be ruled out.
• Harden database privileges so the WordPress database account has only the minimum permissions required for normal operation.