CVE-2023-2732

What it actually does

The MStore API plugin for WordPress versions up to and including 3.9.2 allows unauthenticated authentication bypass through insufficient validation of the user identifier supplied to an add-listing REST API request. An attacker who knows or can enumerate a valid WordPress user ID can cause the application to authenticate them as that user, including an administrator, resulting in full compromise of confidentiality, integrity, and availability for the WordPress site.

Why it matters to the business

Successful exploitation can give an external attacker administrative control of an affected WordPress site, enabling content defacement, malware or skimmer injection, user data theft, creation of persistent backdoor accounts, SEO spam, and disruption of e-commerce or publishing operations. The high CVSS score, network-exploitable unauthenticated attack path, high EPSS probability, and weaponized exploit maturity make this a high-priority issue even though it is not currently listed in CISA KEV.

How an attack unfolds

An attacker first identifies a WordPress site using the vulnerable MStore API plugin. They then determine a valid WordPress user ID, commonly by enumerating public author archives, REST API user data, page metadata, or predictable administrator IDs. The attacker sends a crafted unauthenticated REST API request to the plugin’s add-listing functionality with the target user ID supplied in the request. Because the vulnerable plugin does not sufficiently verify that the requester is authorized to act as that user, the site may establish an authenticated session or otherwise treat the attacker as the selected account. If the chosen account is an administrator, the attacker can access the WordPress admin interface, install malicious plugins or themes, modify PHP files, create new administrator users, alter site content, and deploy persistence or malware.

How to fix it

Upgrade the MStore API plugin to a version newer than 3.9.2 if a patched release is available from the vendor. If no fixed version is available or an immediate upgrade cannot be performed, disable and remove the plugin until a secure release is installed. Restrict access to WordPress REST API endpoints where operationally feasible using a web application firewall or reverse proxy rule, especially routes associated with the MStore API add-listing functionality. Review all WordPress administrator accounts, rotate passwords, invalidate active sessions, and remove any unknown users, plugins, themes, or modified PHP files after remediation. Keep WordPress core, themes, and all plugins updated, and enforce least privilege and multifactor authentication for administrator accounts where supported.

How to confirm the fix worked

Confirm that the installed MStore API plugin version is greater than 3.9.2 or that the plugin has been disabled or removed. From the WordPress admin interface or filesystem, verify the plugin version recorded for the MStore API plugin. Test that unauthenticated requests to MStore API add-listing REST endpoints cannot authenticate, create a session, or act on behalf of an arbitrary user ID. Validate that REST API access controls return an authentication or authorization failure for anonymous requests attempting privileged actions. Review web server and WordPress logs after patching to ensure no continued successful access to the vulnerable route occurs.

Typical attack path

1. Scan for WordPress sites exposing the MStore API plugin or its REST API endpoints.
2. Enumerate valid WordPress user IDs, prioritizing administrator or privileged users.
3. Send a crafted unauthenticated add-listing REST API request containing the chosen user ID.
4. Obtain an authenticated session or authorization context for the targeted user.
5. Access the WordPress admin dashboard or privileged API functions as that user.
6. Create persistence, such as a new administrator account, malicious plugin, web shell, or modified theme file.
7. Use the compromised site for data theft, malware delivery, spam, defacement, or further infrastructure abuse.

How to detect it

Investigate web server access logs, WordPress application logs, WAF logs, CDN logs, and authentication/session logs for unauthenticated requests to MStore API REST endpoints, especially add-listing functionality that includes a user ID or author ID parameter. Look for POST requests to /wp-json/ routes associated with the plugin followed shortly by successful access to /wp-admin/ from the same IP address, new administrator account creation, plugin or theme installation, theme editor activity, or file modifications under wp-content. Review WordPress database-independent audit sources, if available, for user creation, role changes, login events, plugin activation, and theme file edits occurring soon after suspicious REST API calls. On the filesystem, look for recently modified PHP files in wp-content/plugins, wp-content/themes, and wp-content/uploads, as well as unfamiliar plugins, backdoor-like filenames, and web shells. Network indicators are likely to be site-specific, so behavioral correlation of anonymous MStore API requests with privileged WordPress actions is the most reliable detection approach.

• /wp-json/
• /wp-json/mstore
• /wp-json/mstore-api
• add_listing
• add-listing
• mstore
• POST /wp-json/
• POST /wp-json/mstore
• POST /wp-json/mstore-api
• /wp-admin/plugin-install.php
• /wp-admin/plugins.php
• /wp-admin/theme-editor.php
• /wp-admin/user-new.php
• /wp-content/plugins/
• /wp-content/themes/
• /wp-content/uploads/

What your security team should do

• Immediately inventory WordPress sites for the MStore API plugin and prioritize any version up to and including 3.9.2 for remediation.
• Upgrade to a patched version newer than 3.9.2, or disable/remove the plugin if no fixed version is available.
• Because exploit maturity is weaponized and EPSS is high, perform compromise assessment on affected sites rather than treating this as patch-only.
• Search logs for unauthenticated POST requests to MStore API REST routes, especially add-listing-related requests containing user identifiers.
• Review WordPress administrator accounts for unexpected additions, privilege changes, recent password resets, and suspicious login activity.
• Inspect wp-content/plugins, wp-content/themes, and WordPress upload directories for recently added PHP files or malicious modifications.
• Rotate credentials and invalidate sessions for privileged WordPress users after remediation if exploitation cannot be ruled out.
• Deploy WAF or reverse proxy rules to block unauthenticated access to vulnerable MStore API add-listing endpoints until remediation is complete.