Exploitation Research Plan - CVE-2026-39671

1. Vulnerability Summary

The Extra Fees for WooCommerce plugin (versions <= 4.3.3) is vulnerable to Cross-Site Request Forgery (CSRF). This occurs because one or more administrative functions—likely responsible for creating, updating, or deleting conditional fees—fail to implement or correctly validate WordPress nonces. An unauthenticated attacker can exploit this by tricking a logged-in administrator into clicking a malicious link or visiting a site containing a forged request, leading to unauthorized configuration changes (e.g., adding hidden fees to the checkout process).

2. Attack Vector Analysis

• Target Endpoint: wp-admin/admin-ajax.php (most likely) or wp-admin/admin-post.php.
• Vulnerable Action: Administrative handlers registered via wp_ajax_ hooks related to fee management.
• Potential Hook Candidates (inferred from plugin functionality):
  • wp_ajax_mt_add_fee_rule
  • wp_ajax_mt_save_settings
  • wp_ajax_mt_delete_fee
• Payload Carrier: HTTP POST parameters (e.g., action, fee_name, fee_value, fee_status).
• Authentication Level: Requires an active session of a user with administrative privileges (e.g., Shop Manager or Administrator).
• Preconditions: WooCommerce must be active as this is an add-on plugin.

3. Code Flow

The vulnerability is expected to follow this execution path:

1. Entry Point: The administrator's browser sends a POST request to admin-ajax.php with a specific action.
2. Hook Trigger: WordPress triggers the corresponding wp_ajax_{action} hook.
3. Vulnerable Handler: The plugin's handler function (e.g., MT_Product_Fees_Admin::save_fee_rule) is executed.
4. Missing Check: The handler fails to call check_ajax_referer() or wp_verify_nonce(). Alternatively, it calls wp_verify_nonce() but fails to exit if the result is false.
5. State Change: The function proceeds to update the database or options table (e.g., update_option('mt_fee_rules', ...) or $wpdb->insert(...)) based on the attacker-controlled $_POST data.

4. Nonce Acquisition Strategy

According to the vulnerability description, nonce validation is "missing or incorrect."

Scenario A: Missing Nonce Validation

If the nonce check is entirely missing, no nonce is required to execute the exploit.

Scenario B: Incorrect Nonce Validation (Fallback)

If a nonce check exists but is bypassed (e.g., result not checked), the agent should still attempt to find where the plugin generates nonces to make the request "look" valid:

1. Search for Nonce Creation: grep -rn "wp_create_nonce" . inside the plugin directory.
2. Identify Script Localization: Find where the plugin enqueues its admin scripts and look for wp_localize_script.
   • Target JS variable: (inferred) mt_fee_admin_obj or extra_fees_params.
3. Extraction via Browser:
   • Identify an admin page where the plugin is active: wp-admin/admin.php?page=woo-conditional-product-fees-for-checkout.
   • Navigate there using browser_navigate.
   • Extract the nonce: browser_eval("window.mt_fee_admin_obj?.nonce").

5. Exploitation Strategy

The goal is to add a new checkout fee rule via CSRF.

1. Discovery: Identify the exact action and parameters.
   • grep -r "add_action.*wp_ajax" wp-content/plugins/woo-conditional-product-fees-for-checkout/
   • Identify the callback function and inspect its parameters (e.g., fee_amount, fee_label).
2. Drafting the Forged Request:
   • Method: POST
   • URL: http://[target]/wp-admin/admin-ajax.php
   • Content-Type: application/x-www-form-urlencoded
   • Payload:
     • action=[IDENTIFIED_ACTION]
     • fee_label=CSRF_HACKED_FEE
     • fee_type=fixed
     • fee_value=1000
     • status=active
3. Execution: Use the http_request tool while providing the admin's cookies to simulate the CSRF.

6. Test Data Setup

1. Install/Activate Dependencies: Ensure WooCommerce is installed and configured.
2. Install Target Plugin: Ensure Extra Fees for WooCommerce <= 4.3.3 is active.
3. Administrative Session: Ensure the agent has access to administrative cookies (the environment usually provides these for the PoC).
4. Reference Data: Create at least one legitimate fee rule manually via WP-CLI or the UI to understand the structure of the data in the database.

7. Expected Results

• The admin-ajax.php endpoint returns a success response (e.g., {"success":true} or 1).
• No "Forbidden" or "403" error is returned despite the absence of a valid nonce.
• A new fee rule appears in the plugin's configuration.

8. Verification Steps

After the http_request is sent, verify the state change using wp-cli:

1. Check Options Table: If the plugin stores rules in an option:
   • wp option get mt_conditional_fee_rules (actual option name to be verified by wp option list).
2. Check Database: If rules are in a custom table:
   • wp db query "SELECT * FROM wp_mt_fee_rules WHERE fee_label = 'CSRF_HACKED_FEE'" (table name to be inferred by wp db tables).
3. Check Checkout (Optional):
   • Navigate to the WooCommerce checkout page as a customer and check if the "CSRF_HACKED_FEE" of $1000 is applied to the total.

9. Alternative Approaches

• Admin-Post Path: If no wp_ajax actions are found, search for admin_post_ hooks which are also common for settings forms.
  • grep -r "admin_post" .
• Bypass via Method Swapping: If the plugin checks nonces only on POST, try sending the same parameters via GET to see if the handler processes $_REQUEST instead of $_POST.
• Settings Save: If fee rules are protected, check if the general plugin settings (e.g., enabling/disabling the entire plugin) are unprotected.