Exploitation Research Plan: CVE-2026-2991 KiviCare Authentication Bypass

1. Vulnerability Summary

The KiviCare – Clinic & Patient Management System (EHR) plugin (<= 4.1.2) contains an authentication bypass vulnerability in its REST API. The vulnerability exists within the patientSocialLogin() function of the App\controllers\api\AuthController class.

The function is designed to authenticate patients using social media providers (Google, Facebook, etc.). However, it fails to perform a server-side verification of the provided access_token with the social provider. Instead, it retrieves a user based on the provided email address and immediately issues authentication cookies using wp_set_auth_cookie(). While it subsequently checks if the user has the 'patient' role and returns a 403 Forbidden response for non-patients (like administrators), the authentication cookies are already included in the HTTP response headers, allowing an attacker to hijack any user session, including administrator accounts.

2. Attack Vector Analysis

• Endpoint: POST /wp-json/kivicare/v1/auth/patient-social-login (inferred prefix kivicare/v1 and controller route auth).
• Target Function: patientSocialLogin() in App\controllers\api\AuthController.
• Authentication: Unauthenticated (Publicly accessible).
• Parameters:
  • email: The email address of the target user (e.g., a known patient or the site administrator).
  • accessToken: An arbitrary string value (as the token verification is skipped/missing).
  • provider: (Optional/Inferred) The social provider name (e.g., 'google').
• Preconditions:
  • The target email must exist in the WordPress database.
  • The REST API must be active (default in WordPress).

3. Code Flow

1. Request Reception: A POST request is sent to kivicare/v1/auth/patient-social-login.
2. Controller Routing: KCRestAPI.php routes the request to AuthController.
3. User Retrieval: patientSocialLogin() receives the email and accessToken parameters.
4. Bypass Point: The code retrieves the WP_User object by the provided email. It proceeds to call wp_set_auth_cookie($user->ID) before verifying the validity of the accessToken or the user's role.
5. Role Verification: After the cookies are set in the response context, the function checks if the user has the patient role.
6. Sink/Leak:
   • If the user is a patient, a 200 OK response is returned with patient data.
   • If the user is NOT a patient (e.g., an Administrator), a 403 Forbidden error is returned. However, because wp_set_auth_cookie was already called, the response headers contain Set-Cookie headers for the target user.

4. Nonce Acquisition Strategy

Based on the nature of login/authentication endpoints in KiviCare (and typical WordPress REST API design for Auth controllers), no nonce is required for this endpoint.

• Authentication endpoints must be reachable by logged-out users who do not yet have a session/nonce.
• AuthController methods typically have 'permission_callback' => '__return_true' for login actions.

5. Exploitation Strategy

Step 1: Exploit a Patient Account (Direct Access)

1. Identify a valid patient email.
2. Send the malicious login request.
3. Capture the authentication cookies and access the patient dashboard.

Step 2: Exploit an Administrator Account (Header Leakage)

1. Identify the administrator's email.
2. Send the malicious login request.
3. Observe the 403 Forbidden status.
4. Extract the wordpress_logged_in_[hash] cookie from the Set-Cookie response headers.
5. Use the extracted cookie to access the WordPress admin area (/wp-admin/).

Target Request (Example):

POST /wp-json/kivicare/v1/auth/patient-social-login HTTP/1.1
Content-Type: application/json

{
    "email": "admin@example.com",
    "accessToken": "pwned",
    "provider": "google"
}

6. Test Data Setup

1. Create Administrator: wp user create exploit_admin admin@kivicare.local --role=administrator --user_pass=password123
2. Create Patient:
   • Use KiviCare's built-in registration or WP-CLI: wp user create exploit_patient patient@kivicare.local --role=patient (Note: Ensure the role slug is patient as used by the plugin).
3. Verify Plugin Version: Ensure KiviCare <= 4.1.2 is active.

7. Expected Results

• For Patient Email: Response 200 OK. The JSON body contains user details. Set-Cookie headers provide valid session cookies.
• For Admin Email: Response 403 Forbidden. The JSON body contains an error message (e.g., "Only patients can login through this method"). Crucially, the HTTP headers still contain Set-Cookie: wordpress_logged_in_....

8. Verification Steps

1. Capture Cookies: Extract the wordpress_logged_in_ cookie from the response of the attack against the administrator email.
2. Authenticated Request: Use the http_request tool to call a restricted admin endpoint using the captured cookie:
   • Endpoint: GET /wp-json/kivicare/v1/config/system-status (registered in ConfigController.php with checkAdminPermission).
3. Confirm Success: If the response returns 200 OK and system status data (PHP version, database info), the bypass is confirmed.

9. Alternative Approaches

If accessToken is not the correct key, try:

• access_token
• token
• social_token

If the route auth/patient-social-login returns 404, verify the registered routes in the plugin's REST initialization by searching for the string "social" in app/controllers/api/AuthController.php (as the provided snippet was truncated). Common variants:

• /kivicare/v1/auth/social-login
• /kivicare/v1/auth/patient-login