CVE-2026-12941: MultiVendorX WordPress Plugin SQLi Flaw

CVE-2026-12941 Overview

CVE-2026-12941 is a SQL Injection vulnerability [CWE-89] in the MultiVendorX – WooCommerce Multivendor Marketplace AI Powered Solutions plugin for WordPress. The flaw exists in all versions up to and including 5.0.9. The plugin fails to properly escape the order_by parameter and does not sufficiently prepare the underlying SQL query. Authenticated attackers with subscriber-level access can append SQL statements to existing queries and extract sensitive data from the database. When the plugin's store approval setting is configured to auto-approve store owners (the default), any logged-in user can self-register as a store_owner through the public Stores REST endpoint to obtain the edit_stores capability required to reach the vulnerable transactions endpoint.

Critical Impact
Authenticated subscribers can escalate to store owner and exfiltrate arbitrary database contents, including user credentials and order data, through the transactions REST endpoint.

Affected Products

MultiVendorX – WooCommerce Multivendor Marketplace AI Powered Solutions plugin for WordPress
All versions up to and including 5.0.9
WordPress sites where store approval is set to automatic (default configuration)

Discovery Timeline

2026-07-16 - CVE-2026-12941 published to NVD
2026-07-16 - Last updated in NVD database

Technical Details for CVE-2026-12941

Vulnerability Analysis

The vulnerability resides in the Transactions REST controller of the MultiVendorX plugin. The order_by parameter supplied by the client flows into a SQL query that is constructed without adequate escaping or use of prepared statements. Because column and ordering identifiers cannot be parameterized safely with $wpdb->prepare() alone, plugins must apply strict allow-list validation. The plugin does not enforce such validation, allowing attacker-controlled SQL fragments to reach the database engine.

Exploitation is gated by the edit_stores capability, which normally restricts access to vendor accounts. However, the plugin exposes a public Stores REST endpoint that permits any authenticated user, including subscribers, to self-register as a store_owner when auto-approval is enabled. This self-service escalation collapses the practical barrier to exploitation to any logged-in account on the target site.

Once elevated, the attacker calls the transactions endpoint and injects payloads through order_by. Typical outcomes include UNION-based data extraction of wp_users records, session tokens stored in usermeta, and WooCommerce order details.

Root Cause

The root cause is insufficient escaping and missing allow-list validation on the order_by parameter in the Transactions REST controller. The relevant code paths are referenced in the plugin source at classes/RestAPI/Controllers/Transactions.php and classes/Transaction/Transaction.php. See the WordPress Plugin Code Reference for Transactions.php L113 and the Transaction.php L274 reference for the exact locations.

Attack Vector

The attack vector is network-based and requires an authenticated subscriber account. The attacker performs two steps: first, a POST to the public Stores REST endpoint to self-register as a store_owner; second, a request to the transactions endpoint with a crafted order_by value carrying appended SQL. No user interaction is required beyond the attacker's own session. Refer to the Wordfence Vulnerability Report for additional detail.

No verified public proof-of-concept code is available. The vulnerability mechanism is documented in the vendor changeset and Wordfence advisory rather than in exploit code.

Detection Methods for CVE-2026-12941

Indicators of Compromise

Unexpected POST requests to the MultiVendorX Stores REST endpoint (/wp-json/) originating from subscriber accounts, followed by role changes to store_owner.
HTTP requests to the plugin's transactions REST endpoint containing SQL keywords such as UNION, SELECT, SLEEP, or -- in the order_by query parameter.
Anomalous read volume from the WordPress database process against wp_users, wp_usermeta, or WooCommerce order tables.
New user registrations closely correlated with immediate elevation to a vendor role.

Detection Strategies

Inspect web server access logs for the order_by parameter containing non-alphanumeric characters, whitespace-encoded SQL, or comment sequences.
Correlate authentication events with role assignment changes in wp_usermeta for wp_capabilities values transitioning from subscriber to store_owner.
Enable WordPress database query logging where feasible and alert on queries referencing sensitive tables sourced from the transactions controller.

Monitoring Recommendations

Deploy a Web Application Firewall (WAF) rule that blocks SQL metacharacters in the order_by parameter for MultiVendorX REST routes.
Monitor the audit trail for the Stores REST endpoint to catch mass self-registration as store_owner.
Alert on outbound data volume spikes from the WordPress host that could indicate database exfiltration.

How to Mitigate CVE-2026-12941

Immediate Actions Required

Upgrade the MultiVendorX plugin to a version later than 5.0.9 that includes the fix committed in changeset 3606843.
Change the plugin's store approval setting from automatic to manual until the site is patched, blocking self-registration as store_owner.
Audit existing users assigned the store_owner role and revoke any accounts that self-registered from a subscriber baseline.
Rotate credentials, WordPress secret keys in wp-config.php, and API tokens if exploitation is suspected.

Patch Information

The vendor addressed the issue in a fix committed to the plugin repository. Review the WordPress Plugin Changeset 3606843 for the exact code changes to the order_by handling in the transactions controller. Sites on versions 5.0.9 and earlier must update to the fixed release.

Workarounds

Restrict access to the plugin's REST endpoints at the reverse proxy or WAF level to trusted IP ranges while a patch is applied.
Disable the MultiVendorX plugin if it is not actively used until the update can be deployed.
Set the store approval option to manual so that subscriber accounts cannot self-elevate to store_owner.
Enforce least-privilege on WordPress database users so the web application cannot read tables outside its operational needs.

bash

# Configuration example: switch MultiVendorX store approval to manual via WP-CLI
wp option patch update multivendorx_general_tab_settings store_approval manual
# Verify current setting
wp option get multivendorx_general_tab_settings --format=json