CVE-2026-33302
Access Control Bypass in OpenEMR ACL Module Prior to
Publication date: 2026-03-19
Last updated on: 2026-03-20
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| open-emr | openemr | to 8.0.0.2 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-863 | The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-33302 is a critical authorization vulnerability in OpenEMR versions prior to 8.0.0.2 affecting the Access Control List (ACL) module function `AclMain::zhAclCheck()`. The function only checked for explicit allow permissions and completely ignored explicit deny permissions. This means that if a user was explicitly denied access but belonged to a group that had allow permission, the user would still be granted access. The vulnerability arises because the deny-over-allow logic was not enforced, allowing group allow permissions to override explicit denies.
This flaw affects module menus and features controlled by ACL, such as Care Coordination and custom module menus, allowing unauthorized access to restricted functions.
How can this vulnerability impact me? :
This vulnerability can lead to incorrect authorization and privilege escalation. Users who are explicitly denied access to certain modules or features can still gain access if they belong to a group with allow permissions. This undermines access control policies and can result in unauthorized users accessing sensitive medical records or management functions within OpenEMR.
The impact includes violation of intended access restrictions, potentially exposing sensitive health information or administrative functions to unauthorized personnel.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
[{'type': 'paragraph', 'content': 'This vulnerability arises from the ACL function `AclMain::zhAclCheck()` in OpenEMR versions prior to 8.0.0.2, which incorrectly grants access if a user belongs to a group with allow permission despite explicit deny entries. Detection involves verifying ACL configurations where users explicitly denied access are members of groups with allow permissions.'}, {'type': 'paragraph', 'content': 'To detect this on your system, you can audit the ACL entries in the OpenEMR database, focusing on entries where users have explicit deny (allowed=0) but belong to groups with allow (allowed=1) permissions for the same module or feature.'}, {'type': 'paragraph', 'content': 'Suggested commands include querying the OpenEMR database ACL tables to find conflicting permissions. For example, using SQL queries to identify users with deny entries who are members of groups with allow entries for the same ACL resource.'}, {'type': 'list_item', 'content': "Query user deny entries: SELECT * FROM acl_table WHERE allowed = 0 AND user_id = 'specific_user';"}, {'type': 'list_item', 'content': "Query group allow entries for groups the user belongs to: SELECT * FROM acl_table WHERE allowed = 1 AND group_id IN (SELECT group_id FROM user_groups WHERE user_id = 'specific_user');"}, {'type': 'paragraph', 'content': 'By comparing these results, you can detect if the vulnerability condition exists where explicit denies are overridden by group allows.'}] [1]
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation step is to upgrade OpenEMR to version 8.0.0.2 or later, where the vulnerability has been fixed by properly enforcing deny-over-allow precedence in the ACL evaluation logic.
If upgrading immediately is not possible, review and adjust ACL configurations to avoid scenarios where users explicitly denied access are members of groups with allow permissions, as this can lead to unauthorized access.
Additionally, monitor and audit user permissions carefully to ensure that explicit deny entries are respected until the patch can be applied.