Exploitation Research Plan: CVE-2026-34891 (IDPay Payment Gateway for Woocommerce)

1. Vulnerability Summary

The IDPay Payment Gateway for Woocommerce plugin (versions <= 2.2.5) contains an unauthenticated information exposure vulnerability. This occurs because certain AJAX handlers or callback endpoints, intended for processing payment notifications from the IDPay server, fail to implement proper authorization checks or cryptographic verification before displaying sensitive order information. An unauthenticated attacker can probe these endpoints to extract Personal Identifiable Information (PII) of customers, such as names, email addresses, phone numbers, and physical addresses, as well as internal order metadata.

2. Attack Vector Analysis

• Endpoint: wp-admin/admin-ajax.php
• Action: idpay_callback or idpay_check_status (inferred based on common gateway patterns in this plugin)
• Vulnerable Parameter: id (transaction ID) or order_id
• Authentication: None required (unauthenticated)
• Preconditions:
  1. WooCommerce must be active.
  2. At least one order must have been attempted or completed using the IDPay gateway to provide a valid target ID.

3. Code Flow

1. The plugin registers an unauthenticated AJAX handler in the gateway class constructor (likely in includes/class-wc-idpay-gateway.php):
   add_action( 'wp_ajax_nopriv_idpay_callback', array( $this, 'handle_callback' ) );
2. The handle_callback (or similar) function is triggered via an HTTP request to admin-ajax.php?action=idpay_callback.
3. The function retrieves a transaction identifier from the request: $id = $_REQUEST['id'];.
4. It fetches the corresponding WooCommerce order: $order = wc_get_order( $id );.
5. Vulnerability Point: Before verifying the authenticity of the request (e.g., checking the IDPay HMAC signature or API key), the code may output order details or logs for debugging purposes or as part of a status check response.
6. The response is sent to the client, containing sensitive customer data extracted from the $order object.

4. Nonce Acquisition Strategy

This specific vulnerability likely resides in a callback/webhook handler. Payment gateway callbacks (from servers like IDPay to WordPress) cannot use standard WordPress nonces because the external server has no way of obtaining the nonce.

• Observation: If the action is registered via wp_ajax_nopriv_, check if check_ajax_referer is used. In callback handlers for payment processors, it is almost always absent or bypassed.
• Verification: If a nonce is required for a frontend status check (rather than a server-to-server callback), it will be localized.
  • JS Variable: window.idpay_params or window.wc_idpay_params (inferred).
  • Extraction Command: browser_eval("window.idpay_params?.nonce")
• Fallback: If the target is the callback handler, no nonce is required.

5. Exploitation Strategy

The goal is to trigger the unauthenticated information leak via a crafted AJAX request.

1. Enumerate IDs: Since WordPress order IDs are typically incremental integers, the attacker can iterate through a range of IDs.
2. Request Construction:
   • URL: http://[TARGET]/wp-admin/admin-ajax.php
   • Method: POST or GET (depending on handler implementation)
   • Parameters:
     • action: idpay_callback (or idpay_verify)
     • order_id: [ID]
3. Payload Execution (using http_request tool):

   {
     "method": "GET",
     "url": "http://localhost:8080/wp-admin/admin-ajax.php?action=idpay_callback&order_id=123"
   }
   

4. Analyze Response: Look for JSON or HTML containing strings like "billing_first_name", "@gmail.com", or physical addresses.

6. Test Data Setup

To verify the exposure, the environment must contain an order linked to the gateway.

1. Configure Gateway: Enable IDPay in WooCommerce settings (use dummy API key test-key).
2. Create Order:

   wp user create victim victim@example.com --role=customer
   # Create an order for the victim
   wp wc order create --customer_id=$(wp user get victim --field=ID) --status=pending --user=victim --billing='{"first_name":"Sensitive","last_name":"User","address_1":"123 Secret St","phone":"555-0199","email":"victim@example.com"}'
   

3. Get Order ID: Note the ID of the created order (e.g., 123).

7. Expected Results

A successful exploit will return a response containing the customer's PII.

• Response Body Example:

  {
    "status": "success",
    "data": {
      "order_id": 123,
      "customer": "Sensitive User",
      "email": "victim@example.com",
      "address": "123 Secret St",
      "phone": "555-0199"
    }
  }
  

• Even if the payment status is "failed," the exposure of the associated order details constitutes the vulnerability.

8. Verification Steps

After the HTTP request, verify that the data received matches the database content for that order:

wp wc order get 123 --field=billing

Compare the output of the CLI command with the HTTP response body. If they match and the HTTP request was made without any cookies/authentication, the vulnerability is confirmed.

9. Alternative Approaches

If idpay_callback does not yield results, try the following common IDPay gateway actions:

• action=idpay_verify
• action=idpay_check_order
• action=idpay_get_transaction

Check for log file exposure:
IDPay gateways often log to wp-content/uploads/wc-logs/idpay-[random-string].log. If the plugin exposes this log name via an AJAX call or localized script, an attacker can download the entire transaction log.

• Search for log generation: grep -r "wc_get_logger" . in the plugin directory.
• Search for log file path exposure: grep -r "get_log_file_path" .