Description

The KiviCare WordPress plugin before 4.5.5 does not perform authorization checks on some of its REST endpoints, allowing unauthenticated attackers to disclose the patient roster and, when a payment gateway is configured, the payment gateway secret key.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-09-01T08:17:00.263Z",
  "pubdate": "2026-09-01T08:17:00.263Z",
  "executiveSummary": "The KiviCare WordPress plugin, in versions prior to 4.5.5, is susceptible to an unauthorized data disclosure vulnerability due to insufficient access control validation within its REST API endpoints.\nThis vulnerability is classified as a Broken Access Control issue, which allows unauthenticated remote attackers to interact with sensitive API functions that should be restricted to authenticated administrative or clinical personnel.\nThe primary impact of this flaw involves the exposure of sensitive Protected Health Information (PHI) contained within the patient roster, as well as the potential disclosure of payment gateway configuration secrets, such as API keys or environment secrets.\nThe vulnerability poses a severe risk to confidentiality and data integrity, as it grants unauthorized entities the ability to scrape private patient data and potentially hijack or manipulate financial transaction flows if payment gateway credentials are compromised.\nExploitation requires no prior authentication, significantly lowering the barrier to entry for malicious actors. Successful exploitation leverages the lack of server-side capability checks on specific REST route handlers, enabling unauthorized read operations on the application database.\nOrganizations using affected versions of KiviCare are at risk of data breaches, non-compliance with privacy regulations (e.g., HIPAA, GDPR), and potential financial fraud.",
  "technicalDetails": "The vulnerability originates from a failure to implement proper 'permission_callback' functions within the REST API route registration for the KiviCare plugin. In the WordPress REST API framework, if a route is registered without an explicit permission callback, or if that callback fails to validate the user's role and capabilities (e.g., 'manage_options' or 'edit_posts'), the endpoint remains accessible to any user, including unauthenticated visitors.\nThe affected component is the plugin's REST API controller, which handles requests for patient management and system configuration. Specifically, the endpoints responsible for fetching the patient roster and retrieving payment gateway settings fail to verify that the requesting user possesses the requisite administrative privileges. Because the REST API acts as a bridge to the application database, the lack of an authorization layer allows direct queries to retrieve and serialize sensitive records in JSON format.\nThe attack flow proceeds as follows: First, an attacker identifies the exposed REST routes, typically under the '/wp-json/kivicare/v1/' namespace. Using a standard HTTP GET request, the attacker probes endpoints associated with patient records or plugin settings. Since the underlying controller methods lack conditional logic to check 'current_user_can()' or verify authentication headers, the server processes the request and executes the database query intended for privileged users.\nThe server subsequently returns the requested data—specifically the full patient list—to the attacker. If the KiviCare plugin has been configured with a payment gateway, the attacker can simultaneously query the settings retrieval endpoint, which may return the unmasked or insufficiently protected gateway secret key stored in the 'wp_options' table.\nThe post-exploitation impact is multifaceted. Exposure of the patient roster leads to a catastrophic breach of PHI, which carries significant legal and ethical implications. Furthermore, the disclosure of payment gateway secrets allows an attacker to intercept, manipulate, or redirect payments, effectively compromising the financial integrity of the clinical practice. The vulnerability is entirely server-side and does not require user interaction, making it highly exploitable through automated scripts that crawl the target WordPress instance for accessible API routes."
}