CVE-2026-3568: 
WordPress vulnerability analysis and mitigation

CVE-2026-3568 is an Insecure Direct Object Reference (IDOR) vulnerability in the MStore API plugin for WordPress, affecting all versions up to and including 4.18.3. The flaw allows authenticated attackers with Subscriber-level access or above to modify arbitrary user meta fields by supplying unvalidated JSON keys to the update_user_profile() function. It was published on April 9, 2026, with a patch made available the same day. The vulnerability carries a CVSS v3.1 base score of 4.3 (Medium), assigned by Wordfence (GitHub Advisory, Wordfence).

The root cause is CWE-639 (Authorization Bypass Through User-Controlled Key). The vulnerable update_user_profile() function in controllers/flutter-user.php reads raw JSON from php://input (line 1012), decodes it (line 1013), authenticates the user via cookie validation (line 1015), and then iterates over the user-supplied meta_data array, passing arbitrary keys and values directly to WordPress's update_user_meta() (line 1080) with no allowlist, blocklist, or sanitization. This allows an attacker to set sensitive meta keys such as wp_user_level (a legacy integer field used in some privilege checks), plugin-specific authorization flags like _wpuf_user_active and aiowps_account_status, and unsanitized billing/profile fields that could introduce Stored XSS visible in admin contexts. Direct manipulation of wp_capabilities is not possible via this vector because it requires a serialized PHP array value (GitHub Advisory, Wordfence).

Authenticated attackers with minimal (Subscriber-level) privileges can escalate effective permissions by setting wp_user_level to a high integer value, bypassing legacy administrator-level checks used by some themes and plugins. They can also manipulate plugin-specific authorization flags to activate or deactivate accounts and alter billing or profile fields with unsanitized content, potentially injecting stored XSS payloads that execute in admin contexts. While full WordPress role escalation via wp_capabilities is not directly achievable, the combination of privilege escalation through legacy meta fields and potential XSS represents a meaningful integrity risk across affected WordPress installations (GitHub Advisory, Wordfence).

As of the time of disclosure, there is no public proof-of-concept exploit and no evidence of in-the-wild exploitation (GitHub Advisory). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.032–0.042%, placing it in the 13th percentile for exploitation likelihood within 30 days. Exploitation requires a valid authenticated session at Subscriber level or above, limiting the attack surface compared to unauthenticated vulnerabilities.

1. Obtain Subscriber-level credentials: Register or obtain a low-privilege WordPress account on a site running MStore API ≤ 4.18.3 (e.g., via open registration or a compromised account).
2. Authenticate and retrieve session cookie: Log in to the WordPress site and capture the authentication cookie (e.g., wordpress_logged_in_*) for use in subsequent API requests.
3. Craft malicious JSON payload: Construct a JSON body targeting the meta_data parameter with arbitrary meta keys, for example:

   {
     "meta_data": {
       "wp_user_level": 10,
       "_wpuf_user_active": "yes",
       "billing_first_name": "<script>alert(1)</script>"
     }
   }

4. Send request to the update profile endpoint: Submit an HTTP POST request to the MStore API's user profile update endpoint (e.g., /wp-json/mstore-api/v3/user/update or equivalent), including the session cookie and the crafted JSON body read from php://input.
5. Verify meta field modification: Confirm that wp_user_level has been set to 10 (administrator-level for legacy checks) or that plugin-specific flags have been altered, granting elevated access or triggering XSS when an administrator views the affected profile (GitHub Advisory, Wordfence).

• Network: Unusual POST requests to MStore API user profile update endpoints (e.g., /wp-json/mstore-api/v3/user/update) containing JSON bodies with sensitive meta keys such as wp_user_level, _wpuf_user_active, or aiowps_account_status.
• Logs: WordPress access logs showing repeated or anomalous POST requests to MStore API endpoints from low-privilege user accounts; PHP error logs referencing flutter-user.php around lines 1012–1080.
• Database: Unexpected changes to the wp_usermeta table, particularly modifications to wp_user_level set to values of 8 or 10, or changes to plugin-specific authorization flags for subscriber-level accounts.
• File System / Admin UI: Stored XSS payloads appearing in user billing or profile fields visible in the WordPress admin panel (e.g., <script> tags in billing_first_name or similar fields).

Update the MStore API plugin to a version beyond 4.18.3, where a patch was released on April 9, 2026 (GitHub Advisory). The patch can be reviewed via the WordPress plugin changeset. As a temporary workaround, site administrators can disable open user registration to reduce the pool of potential attackers, or use a Web Application Firewall (WAF) rule to block POST requests to the MStore API profile update endpoint containing unexpected meta keys. Additionally, monitor the wp_usermeta database table for unauthorized changes to sensitive fields such as wp_user_level.

The vulnerability was reported and assigned by Wordfence, which published a threat intelligence entry for it (Wordfence). It received standard automated coverage across CVE aggregation platforms (NVD, CIRCL, VulDB) and was noted on Bluesky via the CVE feed bot. No significant independent researcher commentary or broader media coverage has been identified beyond routine vulnerability database entries.