CVE-2026-2991: KiviCare WordPress Authentication Bypass

CVE-2026-2991 Overview

The KiviCare – Clinic & Patient Management System (EHR) plugin for WordPress contains a critical Authentication Bypass vulnerability affecting all versions up to and including 4.1.2. This vulnerability exists in the patientSocialLogin() function, which fails to verify the social provider access token before authenticating users. This flaw allows unauthenticated attackers to bypass credential verification entirely and gain unauthorized access to patient accounts containing sensitive medical records.

Critical Impact

Attackers can log in as any registered patient by providing only an email address and an arbitrary access token value, bypassing all authentication controls and gaining access to protected health information (PHI), medical records, appointments, prescriptions, and billing data.

Affected Products

• KiviCare – Clinic & Patient Management System (EHR) WordPress plugin versions up to and including 4.1.2
• WordPress sites utilizing KiviCare for patient management
• Healthcare systems relying on KiviCare social login functionality

Discovery Timeline

• March 18, 2026 - CVE-2026-2991 published to NVD
• March 19, 2026 - Last updated in NVD database

Technical Details for CVE-2026-2991

Vulnerability Analysis

This Authentication Bypass vulnerability (CWE-287) stems from improper verification of social authentication tokens in the KiviCare plugin's login mechanism. The patientSocialLogin() function located in the AuthController.php file processes social login requests without validating that the provided access token is legitimate or corresponds to the claimed user identity.

The vulnerability has significant implications for healthcare data security. When exploited, an attacker gains access to sensitive medical records, appointments, prescriptions, and billing information—constituting both a PII and PHI breach with potential HIPAA compliance ramifications.

Additionally, a secondary issue compounds the vulnerability's severity: authentication cookies are set in the HTTP response headers before the user role check is performed. While non-patient users (including administrators) receive a 403 response, the authentication cookies are still transmitted in the response headers. This design flaw could potentially be leveraged for further attacks against privileged accounts.

Root Cause

The root cause lies in the patientSocialLogin() function's failure to validate the social provider access token against the external authentication provider's API. The function accepts user-provided email addresses and arbitrary access token values without verification, trusting the client-supplied data implicitly. This violates secure authentication principles by not confirming the identity assertion with the authoritative source (the social identity provider).

Attack Vector

The attack is network-based and requires no prior authentication or special privileges. An attacker can exploit this vulnerability by:

1. Identifying a target patient's email address registered in the KiviCare system
2. Sending a crafted social login request to the vulnerable endpoint
3. Providing the victim's email address along with any arbitrary value as the access token
4. Receiving valid authentication cookies that grant access to the victim's patient account

Since the function does not validate the access token with the social provider, the attacker bypasses all credential verification. The attack complexity is low, requiring no user interaction, and results in complete compromise of patient account confidentiality and integrity.

The vulnerable code paths can be examined in the KiviCare AuthController.php at line 284 and line 1852.

Detection Methods for CVE-2026-2991

Indicators of Compromise

• Unusual login activity from social login endpoints without corresponding social provider authentication logs
• Multiple patient account accesses originating from the same IP address or session
• Login attempts with email addresses but no valid social provider token exchange in server logs
• Abnormal access patterns to patient medical records, prescriptions, or billing information

Detection Strategies

• Monitor WordPress authentication logs for social login attempts that lack proper token validation callbacks
• Implement alerting for multiple failed or suspicious authentication attempts to the KiviCare social login API endpoints
• Review HTTP response headers for authentication cookie issuance patterns, particularly those accompanying 403 responses
• Deploy Web Application Firewall (WAF) rules to detect anomalous patterns in social login request payloads

Monitoring Recommendations

• Enable detailed logging on the KiviCare plugin's AuthController.php endpoints
• Set up SIEM alerts for authentication events involving the patientSocialLogin() function
• Monitor for unauthorized access to patient PHI and trigger immediate incident response protocols
• Implement user behavior analytics to detect account takeover patterns in healthcare records access

How to Mitigate CVE-2026-2991

Immediate Actions Required

• Update the KiviCare plugin immediately to a patched version (version 4.1.3 or later)
• Audit all patient accounts for signs of unauthorized access or data exfiltration
• Review authentication logs for exploitation attempts during the exposure window
• Consider temporarily disabling social login functionality until the patch is applied
• Notify affected patients if evidence of unauthorized access is discovered per HIPAA breach notification requirements

Patch Information

A security patch addressing this vulnerability is available in the WordPress KiviCare Changeset 3467409. Site administrators should update to the latest version of the KiviCare plugin as soon as possible. The patch implements proper access token validation with the social identity provider before authenticating users.

Additional vulnerability details are available through the Wordfence Vulnerability Intelligence report.

Workarounds

• Disable the social login functionality in KiviCare settings until the patch can be applied
• Implement additional authentication factors at the WordPress or network level for patient portal access
• Use a Web Application Firewall to block suspicious requests to the social login endpoints
• Restrict access to the patient management system to known IP ranges where operationally feasible

# Temporarily disable social login by restricting access to the endpoint
# Add to .htaccess or nginx configuration
# Apache .htaccess example:
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{REQUEST_URI} ^/wp-json/kivicare/api/v2/auth/social-login [NC]
    RewriteRule .* - [F,L]
</IfModule>