CVE-2026-104135 in OpenEMR
Summary
by MITRE • 11/05/2026
OpenEMR is a free and open source electronic health records and medical practice management application. Prior to 8.3.0, library/ajax/payment_ajax.php validates a CSRF token but performs no AclMain authorization check before executing a wildcard search of patient_data. Any authenticated user, including a non-clinical role, can enumerate patient identifiers, full names, and dates of birth through the set_patient branch. This issue is fixed in version 8.3.0.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 11/05/2026
OpenEMR serves as a widely deployed open-source electronic health records system designed to manage medical practice workflows and patient data. The vulnerability identified within versions prior to 8.3.0 resides specifically in the library/ajax/payment_ajax.php module, which handles asynchronous payment-related requests. While this endpoint correctly implements Cross-Site Request Forgery protection by validating CSRF tokens, it fails to enforce proper Access Control List authorization checks before executing database queries. This architectural oversight creates a critical gap between authentication and authorization, allowing any user who has successfully authenticated into the system to bypass intended role-based restrictions.
The core technical flaw involves an improper access control mechanism where the application performs a wildcard search against the patient_data table without verifying if the requesting user possesses the necessary permissions for that specific action. In typical secure implementations of such systems, operations involving sensitive health information must be gated by both session validity and explicit permission checks tied to the user's role profile. Here, the absence of an AclMain authorization check means that even users with non-clinical roles, such as administrative staff or billing clerks who should not have access to detailed patient records, can execute these queries. This represents a classic instance of broken object level authorization where the system trusts the user's identity but fails to validate their privilege scope for the specific resource being accessed.
The operational impact of this vulnerability is severe due to the sensitivity of the data exposed through the set_patient branch. An authenticated attacker with low privileges can enumerate patient identifiers, full names, and dates of birth by manipulating request parameters to trigger wildcard searches. This capability allows for significant information disclosure, potentially leading to privacy violations under regulations such as HIPAA in the United States or GDPR in Europe. Beyond immediate data leakage, this vulnerability facilitates further attacks including identity theft, social engineering campaigns targeting specific patients based on their demographic details, and potential escalation of privileges if combined with other vulnerabilities within the application logic.
From a classification perspective, this issue aligns with CWE-284 Improper Access Control, specifically highlighting failures in enforcing restrictive policies for authorized users. It also maps to MITRE ATT&CK technique T1078 Valid Accounts, as it leverages legitimate credentials to access unauthorized resources, and potentially T1530 Data from Cloud Storage if the backend database is considered part of a broader data ecosystem. The vulnerability underscores the importance of implementing defense-in-depth strategies where multiple layers of security controls, including CSRF protection and strict role-based access control, work in tandem rather than relying on single-point defenses.
To mitigate this risk, organizations running OpenEMR versions prior to 8.3.0 must upgrade immediately to version 8.3.0 or later, which includes the necessary code changes to enforce proper authorization checks before executing patient data queries. For environments where immediate patching is not feasible due to operational constraints, temporary mitigations should include restricting network access to the OpenEMR application interface to trusted internal networks only and implementing strict web application firewall rules that monitor for unusual patterns of database enumeration or excessive read operations on sensitive tables. Additionally, auditing user roles ensures that non-clinical staff are assigned minimal permissions consistent with their job functions, reducing the blast radius if such vulnerabilities exist in other parts of the system. Regular security assessments and code reviews focusing on access control logic across all AJAX endpoints are recommended to prevent similar flaws from being introduced during future development cycles.