CVE-2026-124483 in OpenEMR
Summary
by MITRE • 11/08/2026
OpenEMR before 8.4.0 contains an incorrect authorization vulnerability because the prescription REST API routes check the patients.med ACL instead of patients.rx and request no specific permission bit, so read-only Medical/History access passes the check. Authenticated staff users can reuse the UI-exposed APICSRFTOKEN to enumerate prescription UUIDs, forge prescriptions for arbitrary patients, and deactivate existing prescriptions tenant-wide.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 11/08/2026
The vulnerability identified in OpenEMR versions prior to 8.4.0 represents a critical failure in access control mechanisms within the application's REST API infrastructure. Specifically, the flaw resides in how prescription-related endpoints validate user permissions against the underlying database Access Control List (ACL). The system incorrectly checks for authorization using the patients.med ACL entry rather than the more restrictive and semantically appropriate patients.rx ACL entry. This misconfiguration creates a significant discrepancy between the intended security policy and its actual enforcement, allowing users with lower privilege levels to perform actions that should be restricted to higher-privileged roles or specific prescription management permissions.
From a technical perspective, the REST API routes responsible for handling prescription data do not enforce any specific permission bit required for reading or modifying prescriptions. Instead, they rely on a broader check against medical history access rights. Consequently, authenticated staff users who possess only read-only access to patient Medical and History records can bypass authorization checks when interacting with prescription endpoints. This architectural oversight means that the application fails to distinguish between viewing general clinical notes and accessing sensitive pharmaceutical data, violating the principle of least privilege which dictates that users should only have access to the minimum level of system functionality necessary for their role.
The operational impact of this vulnerability is severe due to its potential for abuse by authenticated attackers. Once an attacker gains valid credentials with read-only medical history access, they can exploit the exposed API endpoints using the APICSRFTOKEN provided in standard UI sessions. This token allows them to enumerate prescription Universally Unique Identifiers (UUIDs) associated with various patients within the system. Beyond mere enumeration, the lack of proper write permissions checks enables attackers to forge prescriptions for arbitrary patients. Furthermore, the vulnerability extends to tenant-wide operations, allowing malicious actors to deactivate existing prescriptions across the entire multi-tenant environment if they have access to any patient data. This capability poses a direct threat to patient safety and healthcare compliance standards such as HIPAA in the United States or GDPR in Europe, where unauthorized alteration of medical records is strictly prohibited.
This vulnerability aligns with CWE-284 Improper Access Control, specifically reflecting issues related to insufficient authorization checks on API endpoints. It also maps to MITRE ATT&CK techniques involving Privilege Escalation and Data Exfiltration via the Application Layer. The ability to enumerate resources corresponds to reconnaissance activities where attackers map out available data structures before launching more targeted attacks like prescription forgery or disruption of care through deactivation.
To mitigate this risk, organizations running OpenEMR must upgrade immediately to version 8.4.0 or later, which addresses these authorization flaws by correcting the ACL checks and enforcing stricter permission bits for prescription-related API routes. In environments where upgrading is not immediately feasible, administrators should implement network-level controls such as Web Application Firewalls (WAF) to restrict access to sensitive REST endpoints based on IP reputation or behavioral anomalies. Additionally, auditing existing user roles ensures that staff members with read-only medical history permissions do not have unnecessary exposure to prescription management APIs. Regular security assessments and penetration testing focused on API authorization logic are recommended to identify similar misconfigurations in other parts of the electronic health record system before they can be exploited by malicious actors seeking to compromise patient data integrity or safety.