Exploitation Research Plan - CVE-2025-14078

1. Vulnerability Summary

The PAYGENT for WooCommerce plugin (versions <= 2.4.6) contains a missing authorization vulnerability in its REST API callback handler. The plugin registers a REST route /wp-json/paygent/v1/check/ intended for Paygent payment notifications (webhooks). However, the paygent_permission_callback function, which is supposed to restrict access to authorized Paygent IP addresses, fails to properly enforce these restrictions (unconditionally returning true or failing to return false in a way that blocks access).

This allows an unauthenticated attacker to send forged payment notifications. The handler paygent_check_webhook processes these notifications without any cryptographic signature verification or shared secret validation, allowing an attacker to manipulate order statuses and inject order notes by providing an arbitrary trading_id (WooCommerce Order ID).

2. Attack Vector Analysis

• Endpoint: POST /wp-json/paygent/v1/check/
• Authentication: Unauthenticated (No WordPress login or Nonce required).
• Payload Format: URL-encoded body (as processed by jp4wc_url_to_array).
• Target Parameters:
  • trading_id: The numeric ID of the WooCommerce order to target.
  • payment_type: Determines which specific webhook logic is triggered (e.g., 02 for Credit Card, 26 for PayPay).
  • payment_status: The status code to report (used for order notes and status logic).

3. Code Flow

1. Entry Point: includes/gateways/paygent/class-wc-paygent-endpoint.php
2. Route Registration: paygent_register_routes() (Line 42) registers the /check route using WP_REST_Server::CREATABLE (POST).
3. Authorization Check: paygent_permission_callback() (Line 199) is called. According to the vulnerability description, this function incorrectly returns true (or lacks a mandatory false return), allowing the request to proceed regardless of the requester's IP.
4. Processing Logic: paygent_check_webhook($request) (Line 61) is executed:
   • It extracts the raw body via $request->get_body().
   • It converts the body string to an array using $jp4wc_framework->jp4wc_url_to_array($body_data).
   • It extracts trading_id, payment_status, and payment_type.
   • It sanitizes the trading_id to get the $order_id via preg_replace( '/[^0-9]/', '', $get_array['trading_id'] ).
   • It retrieves the order via wc_get_order( $order_id ).
5. Sink: If the order exists, it adds an order note (Line 131) or calls specific gateway handlers like $this->paygent_cc_webhook( $order, $get_array ) (Line 104), which typically transitions the order to a "Processing" or "Completed" status.

4. Nonce Acquisition Strategy

This vulnerability resides in a REST API endpoint where the permission_callback is misconfigured.

• Is a nonce needed? No. REST API endpoints typically use the _wpnonce parameter only when authenticated via session cookies. Since the permission_callback is vulnerable and intended for third-party webhooks, it does not expect or verify a WordPress nonce.
• Bypass: The vulnerability itself is the bypass of the permission_callback.

5. Exploitation Strategy

The goal is to forge a payment success notification for an existing order.

1. Step 1: Identify a Target Order:
   Obtain a valid WooCommerce Order ID. In a test environment, this can be done via WP-CLI.

2. Step 2: Craft the Forged Webhook Payload:
   Construct a URL-encoded string containing Paygent-style parameters.

   • trading_id=[ORDER_ID]
   • payment_type=02 (Credit Card)
   • payment_status=20 (Typical "Success" or "Authorized" code in Paygent logic, though any value will trigger at least an order note).

3. Step 3: Send the Request:
   Use the http_request tool to send a POST request to the target endpoint.

   Request Details:

   • Method: POST
   • URL: http://[TARGET_HOST]/wp-json/paygent/v1/check/
   • Headers: Content-Type: application/x-www-form-urlencoded
   • Body: trading_id=123&payment_type=02&payment_status=20

4. Step 4: Analyze the Response:
   The endpoint responds with header( 'Content-type: text/plain; charset=utf-8' ); echo 'result=0';. A response of result=0 indicates the plugin processed the "notification".

6. Test Data Setup

1. Ensure WooCommerce is installed and active.
2. Ensure PAYGENT for WooCommerce (v2.4.6) is installed and active.
3. Create a dummy product and place an order as a guest to generate an Order ID.
   • wp eval "wc_create_order(['customer_id' => 0]);" (or use the UI).
4. Note the Order ID (e.g., 123).

7. Expected Results

• The HTTP response body should be exactly result=0.
• The targeted WooCommerce order should have a new note added by the system.
• Depending on the payment_type handler (e.g., paygent_cc_webhook), the order status may change from pending to processing or on-hold.

8. Verification Steps

1. Check Order Notes:
   Use WP-CLI to verify that the webhook injected a note.

   wp order note list [ORDER_ID]
   

   Look for: "I received a payment information inquiry telegram with a payment status of ..."

2. Check Order Status:

   wp order get [ORDER_ID] --field=status
   

   Check if the status transitioned away from pending.

3. Check Debug Logs (if enabled):
   The plugin calls $jp4wc_framework->jp4wc_debug_log. If debugging is active for the gateway, check wp-content/uploads/wc-logs/wc-paygent-....

9. Alternative Approaches

If the 02 (Credit Card) payment_type requires complex additional parameters (like specific Paygent transaction IDs), try other payment types:

• payment_type=26 (PayPay)
• payment_type=03 (Convenience Store)

Even if the internal webhook handlers (paygent_cc_webhook, etc.) fail due to missing secondary parameters, the primary paygent_check_webhook function will still execute:

$order->add_order_note( sprintf( __( 'I received a payment information inquiry telegram with a payment status of %s.', 'woocommerce-for-paygent-payment-main' ), $status_array[ $payment_status ] . ':' . $payment_status ) );

This confirms the unauthorized access and the ability to manipulate order metadata.