Description

OpenEMR is a free and open source electronic health records and medical practice management application. Prior to 8.3.0, the search_persons action in library/ajax/person_search_ajax.php validates CSRF but does not perform an AclMain authorization check before searching the person and patient_data tables. A low-privilege authenticated user can iterate name prefixes and receive patient first and last names, dates of birth, gender, phone numbers, and email addresses in JSON responses. This issue is fixed in version 8.3.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-11-05T20:17:38.827Z",
  "pubdate": "2026-11-05T20:17:38.827Z",
  "executiveSummary": "A vulnerability exists in OpenEMR prior to version 8.3.0, involving an improper authorization check during patient search operations.\nThe vulnerability is classified as an authorization bypass, specifically an Insecure Direct Object Reference (IDOR) or broken access control, residing within the library/ajax/person_search_ajax.php script.\nWhile the application enforces Cross-Site Request Forgery (CSRF) validation, it fails to verify that the authenticated user possesses the appropriate Access Control List (ACL) permissions required to query the person and patient_data tables.\nThis flaw allows low-privilege authenticated users to perform unauthorized queries against the system database.\nThe impact includes the mass exfiltration of sensitive Protected Health Information (PHI), such as full names, dates of birth, gender, phone numbers, and email addresses.\nThe attack is highly accessible, requiring only an authenticated session and no elevated privileges. By iterating through common name prefixes, an attacker can systematically scrape the entire patient database, leading to significant privacy violations, potential regulatory non-compliance (such as HIPAA), and exposure of medical records.",
  "technicalDetails": "The root cause of this vulnerability is the absence of an AclMain authorization check within the search_persons action handled by library/ajax/person_search_ajax.php. In OpenEMR, the AclMain subsystem is responsible for verifying that an authenticated session holds the necessary privileges to perform specific business logic actions.\nAlthough the endpoint correctly validates CSRF tokens to ensure the request originated from the legitimate application interface, it fails to perform server-side verification of user roles before executing SQL queries against the person and patient_data tables.\nThe attack flow follows a predictable pattern: 1) The attacker establishes a valid low-privilege user session within the OpenEMR instance. 2) The attacker crafts an HTTP GET or POST request to library/ajax/person_search_ajax.php, targeting the search_persons action. 3) Because the server-side code does not validate user permissions, the application accepts input parameters such as name prefixes for database queries. 4) The server executes a database query that returns JSON-formatted results containing sensitive patient fields including first name, last name, date of birth, gender, phone numbers, and email addresses.\nSince the endpoint permits partial string matching or prefix-based searching, an attacker can automate the exploitation process by iterating through common character strings or permutations. This allows the attacker to systematically enumerate the entire patient directory, effectively bypassing intended data access restrictions.\nThis vulnerability affects OpenEMR versions prior to 8.3.0. The lack of authorization checks implies that any user with access to the application interface can access patient data regardless of their role or clinical department. This constitutes a severe failure in the application's security architecture, specifically regarding the Principle of Least Privilege.\nPost-exploitation, the attacker gains access to a comprehensive repository of patient demographic and contact information. This data is highly valuable for secondary attacks, including spear-phishing campaigns against patients or further targeted exploitation of the medical management environment. Given the nature of OpenEMR as an electronic health record system, the exposure of these data points represents a direct violation of patient confidentiality and data protection standards."
}