CVE-2026-104136 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, the new_recall branch of interface/main/messages/save.php accepts a caller-supplied pid without enforcing patient-level or recall-workflow authorization. A low-privilege authenticated user who knows or enumerates a patient identifier can retrieve patient details, contact fields, HIPAA notification preferences, recent appointment information, and existing recall information. This issue is fixed in version 8.3.0.
Be aware that VulDB is the high quality 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 new_recall branch of the interface/main/messages/save.php script. This component is responsible for handling recall notifications, which are automated messages sent to patients regarding upcoming appointments or required follow-ups. The core technical flaw stems from a failure to enforce proper authorization checks on the patient identifier parameter provided by the caller. Specifically, the application accepts a pid value without verifying whether the authenticated user initiating the request has legitimate access rights to view data associated with that specific patient ID. This represents a classic Broken Access Control vulnerability where the system relies on client-supplied input for security decisions rather than server-side validation of permissions against the requested resource.
The operational impact of this flaw is significant due to the sensitive nature of healthcare data protected under regulations such as HIPAA in the United States and similar privacy laws globally. A low-privilege authenticated user, who might be a receptionist or administrative staff member with limited access rights, can exploit this weakness by manipulating the pid parameter. By enumerating valid patient identifiers through brute force or other discovery methods, an attacker can retrieve detailed personal information belonging to patients they are not authorized to view. The exposed data includes sensitive contact fields, HIPAA notification preferences which dictate how a patient wishes to be contacted regarding privacy matters, recent appointment history that reveals medical visit patterns, and existing recall information. This unauthorized access allows for the exfiltration of protected health information without triggering typical security alerts associated with high-privilege breaches or external attacks.
From a classification perspective, this vulnerability aligns directly with CWE-284 Improper Access Control, as it involves insufficient restrictions on actions performed by authenticated users. It also maps to MITRE ATT&CK technique T1078 Valid Accounts, where the attacker leverages legitimate credentials to access resources they should not have permission to view. The ability to enumerate patient IDs and subsequently harvest detailed records facilitates data aggregation that could be used for identity theft, social engineering attacks against patients, or targeted phishing campaigns using accurate personal details obtained from the health record system.
To mitigate this risk, organizations running OpenEMR must upgrade immediately to version 8.3.0 or later, where the authorization logic has been corrected to enforce patient-level and recall-workflow permissions before processing requests. For environments that cannot patch instantly due to operational constraints, temporary mitigations should include implementing strict input validation on the pid parameter at a network level using web application firewalls to block suspicious enumeration patterns. Additionally, auditing logs for unusual access patterns involving low-privilege accounts accessing disparate patient records can help detect exploitation attempts in real-time. Ensuring that all user roles are strictly defined with least-privilege principles and regularly reviewing access control lists is essential to prevent similar authorization bypasses across the application suite.