CVE-2025-14977 Exploit & Vulnerability Analysis

1. Vulnerability Background

What is this vulnerability?

• CVE-2025-14977 is an Insecure Direct Object Reference (IDOR) vulnerability in the Dokan AI Powered WooCommerce Multivendor Marketplace Solution WordPress plugin.
• It affects versions up to and including 4.2.4.
• The flaw is located in the REST API endpoint /wp-json/dokan/v1/settings.

Why is it critical/important?

• The endpoint exposes vendor store settings, including highly sensitive payout configuration.
• An authenticated user with customer-level permissions or higher can use a manipulated request to read or modify another vendor’s store settings.
• This enables disclosure of payment credentials and direct takeover of payment destination data such as PayPal email, bank account fields, routing numbers, IBAN, and SWIFT codes.
• Successful exploitation can lead to financial theft when marketplace payouts are processed.

What systems/versions are affected?

• Dokan plugin for WordPress
• Versions up to and including 4.2.4
• Any WordPress install using the plugin and exposing the REST API endpoint for store settings

2. Technical Details

Root cause analysis

• The vulnerability is caused by insufficient validation and authorization in the store settings REST controller.
• In includes/REST/StoreSettingController.php, the update path accepted a user-controlled identifier and passed the full request payload directly into the vendor update function.
• In includes/REST/StoreController.php, the parent store controller did not correctly resolve vendor access for the requested ID, allowing arbitrary vendor record access.

Attack vector and exploitation conditions

• Attacker must be authenticated with at least customer-level privileges.
• The attacker sends requests to /wp-json/dokan/v1/settings with a crafted vendor_id or id parameter pointing to another vendor.
• The endpoint returns store settings or modifies them without enforcing that the requester owns or is authorized for that vendor.
• The attacker can enumerate vendor IDs and issue read/update operations against other vendors.

Security implications

• Exposure of sensitive payment information for third-party vendors.
• Ability to hijack payout configuration by setting attacker-controlled PayPal email or bank details.
• Potential for financial loss from diverted marketplace payouts.
• Breach of vendor confidentiality and marketplace trust.

3. Patch Analysis

What code changes were made?

• In includes/REST/StoreSettingController.php:

  • Old code obtained a vendor object and updated it using all request parameters:
    • get_vendor( $request )
    • get_params()
    • dokan()->vendor->update( $vendor->get_id(), $params )
  • Fixed code now:
    • extracts vendor_id explicitly from the request
    • casts it to integer
    • sets the request’s id parameter
    • delegates the update to parent::update_store( $request )

• In includes/REST/StoreController.php:

  • get_store() was updated to resolve the requested vendor ID through get_vendor_id_for_user() and validate the store exists.
  • update_store_permissions_check() was changed from a simplistic user ID equality check to:
    • resolve vendor/staff ID to a canonical vendor ID
    • call can_access_vendor_store() to verify access

How do these changes fix the vulnerability?

• Explicitly extracting and casting vendor_id removes the previous lack of validation and prevents attackers from abusing arbitrary request parameters.
• Delegating to the parent controller ensures authorization is applied consistently by centralized access control logic.
• Resolving vendor IDs and vendor staff associations prevents attackers from bypassing checks by using related identifiers.
• Returning a 404 for invalid or unauthorized stores avoids leaking whether a vendor ID exists.

Security improvements introduced

• Whitelist-oriented input handling instead of passing entire request data into update logic.
• Stronger authorization enforcement for store access.
• Clear separation between request parameter handling and vendor update operations.
• Better handling of vendor staff vs vendor owner access.

4. Proof of Concept (PoC) Guide

Prerequisites for exploitation

• Dokan plugin version <= 4.2.4 installed and active
• Valid authenticated WordPress account with at least customer-level permissions
• Ability to issue REST API requests to the target site

Step-by-step exploitation approach

1. Authenticate to the WordPress REST API using valid credentials.
2. Identify a target vendor ID in the marketplace.
3. Issue a request to the vulnerable endpoint with the target vendor ID:
   • For read: access /wp-json/dokan/v1/settings?vendor_id=<target_vendor_id> or equivalent GET request
   • For update: send a POST/PUT to /wp-json/dokan/v1/settings with payload including vendor_id=<target_vendor_id> and fields to modify
4. Observe whether the response contains another vendor’s store settings, or whether the update is accepted.

Expected behavior vs exploited behavior

• Expected behavior: only the authenticated vendor or authorized admin can read/update their own store settings.
• Exploited behavior: any authenticated customer-level user can specify another vendor ID and access or modify that vendor’s settings.

How to verify the vulnerability exists

• Verify that a customer-level account can access /wp-json/dokan/v1/settings for a vendor ID that is not their own.
• Verify that the same account can update payout fields such as PayPal email or bank details for another vendor and see the changes take effect.
• Check logs or vendor settings to confirm unauthorized access.

5. Recommendations

Mitigation strategies

• Apply the vendor’s patch or update Dokan to a version newer than 4.2.4.
• If patching is not immediately possible, restrict access to the REST API endpoint using additional access controls or host-level rules.
• Disable unnecessary REST endpoints for non-admin users when possible.

Detection methods

• Monitor REST API access to /wp-json/dokan/v1/settings.
• Alert on requests containing vendor_id parameters from accounts that do not own the referenced vendor.
• Track changes to payout settings and payment destination fields from non-owner accounts.
• Review audit logs for anomalous store settings access or updates.

Best practices to prevent similar issues

• Do not pass entire request payloads directly into update functions.
• Validate and sanitize all user-controlled identifiers explicitly.
• Enforce authorization checks at the controller layer before loading or modifying sensitive resources.
• Centralize access control logic and resolve tenant relationships (vendor/staff) consistently.
• Test REST endpoints for IDOR conditions in multi-tenant applications.