CVE-2026-33302: 
OpenEMR vulnerability analysis and mitigation

CVE-2026-33302 is an incorrect authorization vulnerability in OpenEMR, a widely used open-source electronic health records (EHR) and medical practice management application. The flaw exists in the AclMain::zhAclCheck() function, which fails to enforce explicit ACL deny rules, allowing authenticated users to bypass access restrictions intended by administrators. All OpenEMR versions prior to 8.0.0.2 are affected. The vulnerability was published on March 19, 2026, and patched in version 8.0.0.2. It carries a CVSS v3.1 base score of 8.1 (High) and a CVSS v4.0 base score of 7.3 (High) (GitHub Advisory).

The root cause is classified as CWE-863 (Incorrect Authorization). The vulnerable function AclMain::zhAclCheck() in src/Common/Acl/AclMain.php (lines 250–314) constructs SQL queries that only retrieve records where allowed = 1, never querying for explicit deny entries (allowed = 0). As a result, the deny-over-allow precedence model is entirely absent: if a user is in any group with an "allow" entry for a given ACL section, access is granted regardless of explicit user-level or group-level deny settings. The fix introduced in version 8.0.0.2 implements a proper precedence order — user deny > user allow > group deny > group allow — by adding separate queries for denied entries and restructuring the return logic accordingly (GitHub Advisory, Patch Commit).

Successful exploitation allows any authenticated OpenEMR user to access and modify protected resources — including patient records, medical data, and configuration settings — even when an administrator has explicitly revoked their individual access. Affected features include Care Coordination (e.g., send_to_hie), custom module menus, and any functionality gated by zhAclCheck(). This creates significant confidentiality and integrity risks in healthcare environments, where unauthorized access to patient data may also constitute a HIPAA compliance violation. Availability is not directly impacted (GitHub Advisory).

No confirmed in-the-wild exploitation has been observed, and no standalone weaponized exploit code is publicly available. The GitHub Security Advisory includes a conceptual proof-of-concept walkthrough describing the logic flaw, but it does not provide runnable exploit code or actionable attack payloads. Exploitation requires authentication and that the target user belongs to a group with an "allow" entry for the targeted ACL section. The EPSS score is approximately 0.038%, indicating low automated exploitation probability at this time. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog (GitHub Advisory).

1. Authenticate: Log in to the OpenEMR instance as a user (e.g., "nurse1") who has been explicitly denied access to a specific ACL section (e.g., send_to_hie) at the user level (module_acl_user_settings: allowed = 0).
2. Verify group membership: Confirm that the user belongs to a group (e.g., "Clinicians") that has an "allow" entry for the same ACL section in module_acl_group_settings (allowed = 1).
3. Trigger the vulnerable code path: Navigate to or invoke any application feature that calls AclMain::zhAclCheck($user_id, 'send_to_hie') — such as the Care Coordination module or a menu item gated by this ACL section.
4. Observe bypass: The function returns true because count_group_allowed > 0, ignoring the user-level deny. The user gains access to the restricted feature or data despite the administrator's explicit deny configuration.
5. Access restricted data/features: The user can now view, interact with, or modify patient records and module features they were intended to be denied access to (GitHub Advisory).

• Logs: OpenEMR application logs showing access to Care Coordination (send_to_hie) or other module features by users who have explicit deny entries in module_acl_user_settings; audit log entries for patient record access by users whose individual ACL is set to deny.
• Database: Discrepancies in module_acl_user_settings where a user has allowed = 0 for a section but activity logs show successful access to that section; review module_acl_group_settings for groups with broad allowed = 1 entries that may be exploited.
• Application Behavior: Users appearing in Care Coordination workflows or accessing module menus (e.g., send_to_hie) despite being individually denied in ACL configuration (GitHub Advisory).

Upgrade OpenEMR to version 8.0.0.2 or later, which implements correct deny-over-allow precedence in zhAclCheck(). As an interim workaround, administrators should audit all group-level ACL assignments and remove users from groups that have "allow" access to sections those users should be denied, since individual deny rules are non-functional in unpatched versions. Additionally, restrict group membership so that only users who should have access to all resources assigned to a group are included in that group (GitHub Advisory, Patch Commit).

The vulnerability was discovered and reported by researchers simecek (reporter), pavelkohout396 and stanislavfortaisle (analysts), with remediation by kojiromike, as credited in the GitHub Security Advisory. Aisle published a blog post highlighting this CVE as part of a broader disclosure of 38 critical security vulnerabilities found in healthcare software used by over 100,000 providers, drawing attention to systemic security issues in EHR platforms (Aisle Blog). The vulnerability was also covered by security aggregators including RedPacket Security and CVEFeed shortly after disclosure (GitHub Advisory).