Exploitation Research Plan: CVE-2025-14978 (PeachPay Order Status Modification)

1. Vulnerability Summary

The PeachPay — Payments & Express Checkout for WooCommerce plugin (up to and including 1.119.8) contains a missing authorization vulnerability in its REST API implementation. Specifically, the endpoint designated for handling ConvesioPay webhooks fails to implement a proper permission_callback or verify the authenticity of the incoming request (e.g., via a shared secret or signature check).

This allows an unauthenticated attacker to send a specially crafted HTTP POST request to the webhook endpoint, specifying an arbitrary WooCommerce Order ID and a desired status, effectively bypassing the payment process.

2. Attack Vector Analysis

• Endpoint: /wp-json/peachpay/v1/convesiopay/webhook (inferred from description)
• HTTP Method: POST
• Authentication: None (Unauthenticated)
• Preconditions:
  • The plugin must be active.
  • WooCommerce must be installed.
  • At least one order must exist in the system (attacker needs the Order ID).
• Payload: A JSON object containing an order_id and a state indicator (e.g., status or event) that triggers the "success" logic in the plugin.

3. Code Flow (Inferred)

1. Registration: The plugin registers a REST route during rest_api_init.
   • File: includes/api/class-peachpay-rest-api.php or similar (inferred).
   • Code: register_rest_route('peachpay/v1', '/convesiopay/webhook', ...)
   • Vulnerability: The permission_callback is likely set to __return_true or omitted, allowing access to anyone.
2. Request Handling: The callback function (e.g., handle_convesiopay_webhook) is invoked.
3. Data Extraction: The function extracts parameters from the WP_REST_Request object (e.g., $request->get_param('order_id')).
4. Order Manipulation:
   • The code fetches the order: $order = wc_get_order($order_id);
   • It checks the status/event in the payload.
   • It calls $order->update_status('completed'); or $order->payment_complete(); without verifying if the request actually originated from ConvesioPay.

4. Nonce Acquisition Strategy

This vulnerability exploits a REST API endpoint intended for webhooks.

• Internal WP Nonces: Webhook endpoints typically do not use WordPress nonces (_wpnonce or X-WP-Nonce) because they are designed to be called by external servers (PeachPay/ConvesioPay) that do not have access to the user's browser session.
• Verification Status: Explicitly no nonce is needed for this exploit.
• Bypass: The vulnerability exists precisely because the developers failed to implement an alternative form of authentication (like a header-based signature) in place of the standard WordPress auth.

5. Exploitation Strategy

The goal is to move a "Pending" or "Failed" order to "Completed" (or "Processing") status.

Step 1: Discover the Order ID

In a real-world scenario, an attacker might guess IDs (sequential) or use their own order ID. For the PoC, we will create an order and use its ID.

Step 2: Send the Webhook Payload

Send a POST request to the REST endpoint. We will test common webhook keys for PeachPay/ConvesioPay.

Request Details:

• URL: http://vulnerable-site.com/wp-json/peachpay/v1/convesiopay/webhook
• Method: POST
• Headers: Content-Type: application/json
• Body (Hypothetical - to be verified by agent):

{
  "order_id": "TARGET_ORDER_ID",
  "status": "SUCCEEDED"
}

Note: If status doesn't work, common alternatives are state, event_type, or payload structures.

6. Test Data Setup

1. Install WooCommerce: Ensure WooCommerce is active.
2. Create a Product: Use WP-CLI to create a dummy product.
   • wp post create --post_type=product --post_title="Test Product" --post_status=publish
3. Create a Pending Order:
   • wp wc order create --user=guest --status=pending --line_items='[{"product_id":PRODUCT_ID, "quantity":1}]'
   • Note the returned Order ID.

7. Expected Results

• HTTP Response: 200 OK or 201 Created.
• System Change: The WooCommerce order status for the targeted ID should change from pending to completed or processing.
• Side Effects: If configured, WooCommerce may trigger "Order Complete" emails to the customer, even though no money changed hands.

8. Verification Steps

After sending the http_request, verify the order status via WP-CLI:

wp wc order get <ORDER_ID> --field=status

If the output is completed or processing, the exploit is successful.

9. Alternative Approaches

If the initial payload format is rejected:

1. Structure Check: The plugin might expect the data wrapped in a specific key, e.g., {"data": {"order_id": 123, "status": "SUCCEEDED"}}.
2. Header Check: Check if the code looks for a specific header (like X-PeachPay-Signature) but fails to die() if it's missing (a common bug).
3. Endpoint Discovery: Use the http_request tool to fetch http://vulnerable-site.com/wp-json/ and grep for peachpay to confirm the exact route namespace and path.
4. Parameter Names: Try id instead of order_id and state instead of status. (These are common in the Convesio/PeachPay SDK).