MStore API – Create Native Android & iOS Apps On The Cloud <= 4.18.4 - Missing Authorization

This research plan targets CVE-2026-57375, a Missing Authorization vulnerability in the MStore API plugin (versions <= 4.18.4). Based on the CVSS vector (I:L, C:N), the vulnerability likely allows unauthenticated attackers to modify specific plugin configurations or user-related data without proper permission checks.

---

1. Vulnerability Summary

• Vulnerability: Missing Authorization.
• Plugin: MStore API – Create Native Android & iOS Apps On The Cloud (mstore-api).
• Afected Versions: <= 4.18.4.
• Description: The plugin registers REST API endpoints or AJAX handlers intended for app synchronization or user management but fails to implement permission_callback (for REST) or capability checks (for AJAX). This allows unauthenticated users to trigger functions that modify site state.

2. Attack Vector Analysis

• Endpoint Type: Likely a WordPress REST API route (registered via register_rest_route) or an unauthenticated AJAX action (wp_ajax_nopriv_).
• Route Namespace (inferred): mstore/v1 or mstore-api/v1.
• Authentication: None required (unauthenticated).
• Preconditions: The plugin must be active. Some endpoints may require a specific plugin setting to be enabled (e.g., "Enable App Login").

3. Code Flow (Discovery Phase)

The agent must first locate the vulnerable entry point.

1. Identify REST Routes: Search for route registrations that lack proper authorization.

   • Command: grep -rn "register_rest_route" wp-content/plugins/mstore-api/
   • Look for: Routes where 'permission_callback' is missing, set to __return_true, or set to a function that doesn't use current_user_can().

2. Identify AJAX Handlers: Search for unauthenticated AJAX actions.

   • Command: grep -rn "wp_ajax_nopriv_" wp-content/plugins/mstore-api/
   • Trace the callback function to check for current_user_can() or check_ajax_referer().

3. Target Functionality: Focus on functions that perform update_option(), update_user_meta(), or wp_insert_user().

   • Command: grep -rnE "update_option|update_user_meta|wp_insert_user" wp-content/plugins/mstore-api/

4. Nonce Acquisition Strategy

While many REST routes in this plugin may skip nonces entirely for mobile compatibility, some might require the standard wp_rest nonce.

1. Check Requirement: Inspect the permission_callback. If it is absent, no nonce is typically required for unauthenticated REST access.
2. Extraction (if needed):
   • Identify a shortcode that enqueues MStore scripts (e.g., [mstore_info] or similar, found via grep -r "add_shortcode").
   • Create a test page: wp post create --post_type=page --post_status=publish --post_content='[SHORTCODE_NAME]'
   • Navigate to the page and extract the nonce using browser_eval:
     window.mstore_vars?.nonce or check the wp-json header.

5. Exploitation Strategy

Based on common patterns in this plugin, the vulnerability likely resides in a "Settings Sync" or "User Registration" endpoint.

Scenario A: Unauthorized Settings Update (Integrity: Low)

If a route like POST /wp-json/mstore/v1/settings exists:

• Endpoint: http://vulnerable-test.local/wp-json/mstore/v1/settings
• Method: POST
• Headers: Content-Type: application/json
• Payload:

  {
      "mstore_app_config": {
          "firebase_server_key": "attacker-key",
          "facebook_app_id": "123456789"
      }
  }
  

Scenario B: Unauthorized User Meta Modification

If a route like POST /wp-json/mstore/v1/user/update exists:

• Endpoint: http://vulnerable-test.local/wp-json/mstore/v1/user/update
• Payload:

  {
      "user_id": 1,
      "meta_key": "some_privilege_flag",
      "meta_value": "true"
  }
  

6. Test Data Setup

1. Install Plugin: Ensure mstore-api v4.18.4 is installed and active.
2. Identify Target Setting: Determine a non-critical but modifiable option (e.g., the "App Name" or "Primary Color" in the plugin settings).
3. Create Page (if nonce needed): Find the script-loading shortcode and place it on a page.

7. Expected Results

• Success Response: The server returns 200 OK or 201 Created, often with a JSON body like {"status": "success"} or echoing the updated values.
• Vulnerability Confirmation: The modified setting or user meta persists in the database.

8. Verification Steps

1. Check Options: Use WP-CLI to see if the targeted option changed.
   • wp option get mstore_app_config
2. Check User Meta:
   • wp user meta get 1 some_privilege_flag
3. Log Inspection: Check for lack of "401 Unauthorized" or "403 Forbidden" responses in the access logs during the unauthenticated request.

9. Alternative Approaches

• Method Override: If POST is blocked, try GET with parameters or use the X-HTTP-Method-Override: POST header.
• Search for Configuration Sync: Many mobile plugins have an "Import/Export" or "Sync" feature that uses a simple token (or no token) to overwrite settings. Search for json_decode(file_get_contents('php://input')) in files related to "Sync" or "Cloud".
• Check for _wpnonce bypass: See if the code calls check_ajax_referer but passes false as the third argument (die) and fails to check the return value.