Float Payment Gateway <= 1.1.9 - Improper Authorization to Unauthenticated Order Status Manipulation

This exploitation research plan targets CVE-2025-15513 in the Float Payment Gateway plugin.

1. Vulnerability Summary

The vulnerability is an Incorrect Authorization issue resulting from improper error handling within the verifyFloatResponse() function. In WooCommerce payment gateways, callback functions (webhooks) are designed to be unauthenticated so that the payment provider (Float) can notify the site of transaction results.

In version <= 1.1.9, the logic within verifyFloatResponse() incorrectly handles failed verification attempts or specific error states. Instead of silently failing or logging an error without modifying the order, the function proceeds to update the order status to "failed." An unauthenticated attacker can exploit this by sending a crafted request to the callback endpoint, specifying a valid WooCommerce Order ID. Even if the attacker cannot forge a valid signature, the plugin's error-handling logic will transition the target order to a "failed" status.

2. Attack Vector Analysis

• Endpoint: The WooCommerce API callback endpoint. This is typically registered via the woocommerce_api_{gateway_id} hook.
• Gateway ID (Inferred): Likely float_gateway or float-gateway. The URL would be /wc-api/float_gateway/.
• Vulnerable Function: verifyFloatResponse() (likely called from a public callback handler).
• Payload Parameter: The Order ID is typically passed via $_GET or $_POST (e.g., order_id, order_number, or as part of a JSON body).
• Authentication: None required (Unauthenticated).
• Precondition: A WooCommerce order must exist in a state that can be transitioned to "failed" (e.g., pending, on-hold).

3. Code Flow (Inferred)

1. Entry Point: The plugin registers a callback for WooCommerce:
   add_action( 'woocommerce_api_float_gateway', array( $this, 'check_float_response' ) );
2. Handler: The handler (e.g., check_float_response) retrieves the request data.
3. Vulnerable Sink: The handler calls verifyFloatResponse($data).
4. Logic Flaw:
   • The function attempts to verify the request signature/integrity.
   • Upon a verification error or a specific "failed" flag in the input, the code calls:
     $order->update_status( 'failed', __('Float payment failed.', 'float-gateway') );
   • Because the verification failure itself triggers the status update, an attacker simply needs to provide a valid Order ID and intentionally invalid signature data to force the "failed" status.

4. Nonce Acquisition Strategy

No nonce is required.
Payment gateway callbacks (webhooks) using the WC_API (e.g., /wc-api/xyz) are designed to be accessed by external servers and do not implement WordPress CSRF nonces. Authorization is usually handled via shared secrets or digital signatures, which this vulnerability allows the attacker to bypass or leverage through the error-handling flaw.

5. Exploitation Strategy

Step 1: Discover the Gateway ID and Parameters

The agent must first identify the exact callback ID and the parameter name used for the Order ID.

• Action: Search for woocommerce_api_ and verifyFloatResponse.
• Target File: Likely includes/class-wc-gateway-float.php or float-gateway.php.

Step 2: Identify the Payload Structure

Determine if the gateway expects a GET or POST request and what the Order ID parameter is (e.g., id, order_id, reference).

Step 3: Trigger Status Change

Send a request to the callback URL with the target Order ID.

• Request Method: POST (or GET, based on Step 2).
• URL: https://TARGET/wc-api/float_gateway/ (Adjust based on discovery).
• Parameters: order_id=[TARGET_ORDER_ID]&signature=invalid_garbage

6. Test Data Setup

1. Install WooCommerce.
2. Activate Float Payment Gateway.
3. Create a Test Order:

   # Create a customer
   wp user create victim victim@example.com --role=customer
   # Create an order for the victim
   ORDER_ID=$(wp wc order create --user=victim --status=pending --porcelain)
   echo "Created Order ID: $ORDER_ID"
   

4. Verify Initial Status:
   wp wc order get $ORDER_ID --field=status (Should be pending).

7. Expected Results

• The server responds with a status code (likely 200 or 400 depending on how the error is handled).
• The WooCommerce order identified by $ORDER_ID is updated.
• The Order Notes will reflect a status change to "failed."

8. Verification Steps

1. Check Order Status via WP-CLI:
   wp wc order get <ORDER_ID> --field=status
   • Success: Returns failed.
2. Check Order Notes:
   wp wc order_note list <ORDER_ID>
   • Look for notes indicating the status was changed by the Float Gateway.

9. Alternative Approaches

If the plugin requires specific JSON formatting:

• Attempt JSON Payload:

  {
      "order_id": "<ORDER_ID>",
      "status": "failure",
      "signature": "invalid"
  }
  

• Header Check: Some plugins check for specific headers (e.g., X-Float-Signature). Try sending the request with a dummy signature header to reach the internal verification logic that contains the error handling flaw.

10. Code Reference (Verbatim Identifiers)

• Function name to audit: verifyFloatResponse
• Hook to search for: woocommerce_api_
• Status Sink: $order->update_status( 'failed', ... )
• Plugin Slug: float-gateway