Appointment Booking Calendar <= 1.6.9.29 - Insecure Direct Object Reference to Authenticated (Staff+) Sensitive Information Exposure

This plan outlines the research and exploitation process for CVE-2026-1704, an Insecure Direct Object Reference (IDOR) vulnerability in the "Simply Schedule Appointments" plugin.

1. Vulnerability Summary

The vulnerability exists in the plugin's REST API implementation for retrieving appointment details. Specifically, the get_item_permissions_check method (likely within SSA_Appointments_Api, inferred from plugin structure) grants access to any user with the ssa_manage_appointments capability.

While this capability is intended for staff/team members, the implementation fails to verify if the requesting staff member is actually assigned to or owns the specific appointment requested via the id parameter. This allows a low-privileged "Team Member" to view sensitive customer Personally Identifiable Information (PII) for appointments belonging to any other staff member.

2. Attack Vector Analysis

• Endpoint: /wp-json/ssa/v1/appointments/(?P<id>\d+) (Inferred based on SSA_Settings_Api patterns in includes/class-settings-api.php).
• HTTP Method: GET
• Vulnerable Parameter: id (The appointment ID).
• Authentication Required: Authenticated user with the ssa_manage_appointments capability.
• Required Role: Typically a user with a "Team Member" role or a custom role granted SSA capabilities.
• Precondition: The "Team Booking" feature must be enabled or the system must have multiple staff members and existing appointments.

3. Code Flow

1. Request Entry: The attacker sends a GET request to /wp-json/ssa/v1/appointments/{id}.
2. Routing: WordPress matches the route registered via register_rest_route.
3. Permission Check: The controller calls get_item_permissions_check($request).
4. Flawed Logic: The method checks current_user_can('ssa_manage_appointments'). If true, it returns true. It does not query the SSA_Appointment_Model to verify if the $request['id'] is associated with the current_user_id.
5. Data Retrieval: The controller calls get_item( $request ), which invokes SSA_Appointment_Model::db_get( $id ).
6. Information Exposure: The response returns the full appointment record, including the customer_information array containing PII (name, email, phone, etc.).

4. Nonce Acquisition Strategy

SSA uses the standard WordPress REST API nonce (wp_rest). This nonce is required for all authenticated ssa/v1 requests.

1. Identify Trigger: The SSA Admin dashboard (/wp-admin/admin.php?page=ssa-settings) loads the main booking application which enqueues the necessary scripts and nonces.
2. Setup Page: A page containing the SSA admin app is needed. Usually, simply logging in as a user with ssa_manage_appointments and visiting the SSA dashboard is sufficient.
3. Navigation: Use browser_navigate to target_url + "/wp-admin/admin.php?page=ssa-settings".
4. Extraction: SSA localizes its data into a global JavaScript object. Based on common plugin patterns:
   • Variable: window.SSA_Data or window.ssa_admin.
   • Command: browser_eval("window.SSA_Data?.rest_nonce || window.ssa_admin?.nonce").
   • Alternative: Extract the standard wp-json nonce from the wp-api-fetch initialization or the _wpnonce in the page source.

5. Test Data Setup

To demonstrate the vulnerability, we need two staff members and one appointment.

1. Create Staff 1 (Victim):

   wp user create victim victim@example.com --role=author --user_pass=password
   # Grant SSA capability (usually handled by the plugin, but we can force it)
   wp cap add author ssa_manage_appointments
   

2. Create Staff 2 (Attacker):

   wp user create attacker attacker@example.com --role=author --user_pass=password
   wp cap add author ssa_manage_appointments
   

3. Create Appointment for Victim:
   Use wp eval to insert directly into the SSA appointments table (table name prefix: wp_ssa_appointments).

   $plugin = Simply_Schedule_Appointments::get_instance();
   $appointment_id = $plugin->appointment_model->insert(array(
       'appointment_type_id' => 1,
       'customer_information' => array(
           'first_name' => 'Secret',
           'last_name' => 'Customer',
           'email' => 'sensitive@victim.com',
           'phone' => '555-0199'
       ),
       'status' => 'booked',
       'staff_ids' => array( [ID_OF_VICTIM_USER] )
   ));
   echo "Created Appointment ID: " . $appointment_id;
   

6. Exploitation Strategy

1. Login: Log in as attacker.
2. Extract Nonce: Navigate to /wp-admin/admin.php?page=ssa-settings and extract the wp_rest nonce.
3. Perform IDOR: Use the http_request tool to fetch an appointment ID belonging to the victim.

HTTP Request:

GET /wp-json/ssa/v1/appointments/[VICTIM_APPOINTMENT_ID] HTTP/1.1
Host: localhost:8080
X-WP-Nonce: [EXTRACTED_NONCE]
Cookie: [ATTACKER_COOKIES]

7. Expected Results

• Vulnerable Version: The server returns a 200 OK response with a JSON body containing the customer_information field with the victim's customer's PII.
• Patched Version: The server returns a 403 Forbidden or 401 Unauthorized because the requester is not the assigned staff member.

8. Verification Steps

1. Analyze Response: Inspect the JSON output for keys: first_name, last_name, email, and phone.
2. Verify Ownership: Use WP-CLI to confirm the appointment belongs to the victim and not the attacker:

   # Check staff_ids for the appointment
   wp db query "SELECT staff_ids FROM wp_ssa_appointments WHERE id = [ID]"
   

9. Alternative Approaches

• List Appointments: If the single item endpoint is protected, check the collection endpoint: GET /wp-json/ssa/v1/appointments. Does it filter by the current user? If not, it's a "Mass Assignment" or "Information Exposure" vulnerability.
• Capability Level: Test if lower roles (subscriber) can access the endpoint if the capability check is entirely missing or incorrectly implemented.
• Meta Model: Check ssa/v1/appointment-meta (inferred from property appointment_meta_model) for similar IDOR vulnerabilities.