COMPE <= 1.1.4 - Unauthenticated Insecure Direct Object Reference

This research plan outlines the process for investigating and demonstrating the Insecure Direct Object Reference (IDOR) vulnerability in the COMPE – WooCommerce Compare Products plugin (CVE-2026-40737).

1. Vulnerability Summary

The COMPE – WooCommerce Compare Products plugin (versions <= 1.1.4) contains an Insecure Direct Object Reference (IDOR) vulnerability. The plugin registers AJAX handlers for managing product comparison lists. These handlers fail to validate that the product or comparison list being modified/deleted belongs to the requester. Consequently, an unauthenticated attacker can manipulate data (e.g., clearing lists or removing items) belonging to other users by providing a different identifier (e.g., a product_id or list_id) in the request.

2. Attack Vector Analysis

• Endpoint: wp-admin/admin-ajax.php
• AJAX Actions (Inferred):
  • compe_remove_product
  • compe_clear_all_products
• Vulnerable Parameters: The parameters used to identify the object to be removed or cleared (e.g., id, product_id, list_key).
• Authentication: Unauthenticated (via wp_ajax_nopriv_* hooks).
• Preconditions: WooCommerce must be active. At least one comparison list or item must exist in the database (or session) for another user to act as a target.

3. Code Flow (Inferred)

1. Entry Point: The plugin registers unauthenticated AJAX hooks in the main class or an AJAX handler class:
   add_action( 'wp_ajax_nopriv_compe_remove_product', array( $this, 'remove_product' ) );
2. Handler Function: The function (e.g., remove_product) retrieves the object identifier from $_POST['id'] or $_POST['product_id'].
3. Missing Authorization: The code proceeds to delete the record from the database (likely using $wpdb->delete or removing from a meta-field/session) using only the provided ID without verifying if the ID is associated with the current requester's session or cookie.
4. Sink: The database is modified, resulting in unauthorized data deletion.

4. Nonce Acquisition Strategy

The plugin likely uses wp_localize_script to pass a security nonce to the frontend.

1. Identify Shortcode: Look for the comparison list shortcode (inferred: [compe_compare]) or check where the "Compare" button is rendered on product pages.
2. Setup Page: Create a public page containing the comparison functionality:
   wp post create --post_type=page --post_status=publish --post_title="Compare" --post_content="[compe_compare]"
3. Extract Nonce:
   • Use browser_navigate to visit the newly created page.
   • Use browser_eval to find the localized JavaScript object. Look for compe_vars, compe_obj, or similar.
   • Execution: browser_eval("window.compe_vars?.nonce") (Verify the exact variable name in the page source).

5. Exploitation Strategy

The goal is to perform an unauthorized "remove" or "clear" action on behalf of another (simulated) user.

1. Step 1: Discover Target ID. Identify a product ID or list identifier currently in use by a "victim" user.
2. Step 2: Obtain Nonce. Use the strategy in Section 4 to get a valid nonce for the wp_ajax_nopriv_ action.
3. Step 3: Craft Unauthorized Request. Send a POST request to admin-ajax.php.
   • Action: compe_remove_product (Verify in source).
   • Payload: action=compe_remove_product&id=[TARGET_PRODUCT_ID]&security=[NONCE]
4. Tooling: Use http_request.

{
  "method": "POST",
  "url": "http://localhost:8080/wp-admin/admin-ajax.php",
  "headers": {
    "Content-Type": "application/x-www-form-urlencoded"
  },
  "body": "action=compe_remove_product&id=123&security=abc123def"
}

6. Test Data Setup

1. Install WooCommerce: Ensure the WooCommerce plugin is active.
2. Create Products: Create at least two test products.
   wp post create --post_type=product --post_title="Target Product" --post_status=publish
3. Simulate Victim Activity: Use a browser or WP-CLI to add a product to a comparison list. Note the database record or meta-value created.
4. Confirm Target ID: Identify the id of the comparison entry to be targeted.

7. Expected Results

• Successful Exploitation: The AJAX response returns a success indicator (e.g., {"success": true}).
• Data Impact: The product entry associated with the id provided in the payload is removed from the database, even though the attacker did not "own" that comparison session.

8. Verification Steps

1. Database Check: Use WP-CLI to check the state of the comparison table or user meta before and after the attack.
   wp db query "SELECT * FROM wp_compe_lists WHERE id = [TARGET_ID];" (Verify table name).
2. UI Check: Navigate to the comparison page as the "victim" to confirm their list has been altered or cleared.

9. Alternative Approaches

• Clear All Action: If compe_remove_product is not the primary vector, investigate compe_clear_all. If it accepts a user_id or list_id parameter without verification, it may allow clearing all items for any user.
• Information Disclosure: Check if any AJAX actions (e.g., compe_get_list) allow retrieving comparison data for arbitrary IDs, which would elevate the IDOR from data modification to data exposure.