CVE-2026-33302: OpenEMR Auth Bypass Vulnerability

CVE-2026-33302 Overview

OpenEMR is a free and open source electronic health records (EHR) and medical practice management application widely used in healthcare environments. A critical authorization bypass vulnerability exists in versions prior to 8.0.0.2 within the module ACL function AclMain::zhAclCheck(). This function only checks for the presence of any "allow" permission (user or group) but never validates explicit "deny" entries where allowed=0. As a result, administrators cannot effectively revoke access by setting a user or group to "deny"; if the user belongs to any group that has "allow" permission, access is granted regardless of explicit deny rules.

Critical Impact

Attackers with low-privileged access can bypass administrator-configured access denials, potentially gaining unauthorized access to sensitive patient health records and medical practice data.

Affected Products

• OpenEMR versions prior to 8.0.0.2
• OpenEMR installations using the ACL module for access control
• Healthcare environments relying on deny-based access revocation

Discovery Timeline

• 2026-03-19 - CVE-2026-33302 published to NVD
• 2026-03-19 - Last updated in NVD database

Technical Details for CVE-2026-33302

Vulnerability Analysis

This vulnerability is classified as CWE-863 (Incorrect Authorization), a broken access control flaw in the ACL permission checking logic. The AclMain::zhAclCheck() function within OpenEMR's Common ACL module implements a flawed authorization model where explicit deny entries are completely ignored during permission evaluation.

The core issue lies in the permission resolution algorithm: when a user requests access to a protected resource, the system queries for any "allow" entry associated with the user directly or through group membership. If any allow entry exists, access is granted immediately without consulting deny entries. This creates a scenario where administrators who believe they have revoked a user's access by setting explicit denies are providing a false sense of security.

In healthcare environments, this vulnerability is particularly concerning as it could allow unauthorized access to protected health information (PHI), violating HIPAA compliance requirements and potentially exposing sensitive patient data.

Root Cause

The root cause is an incomplete implementation of the ACL permission resolution logic in src/Common/Acl/AclMain.php. The zhAclCheck() function queries for allow permissions but lacks the corresponding logic to evaluate deny entries (allowed=0). Proper ACL implementations should evaluate deny rules with higher precedence than allow rules, or at minimum, check for explicit denies when making authorization decisions.

Attack Vector

An attacker with a low-privileged user account can exploit this vulnerability through the following attack scenario:

1. The attacker is a member of a group that has "allow" permissions for certain resources
2. An administrator explicitly sets a "deny" entry for the attacker's user account to revoke access
3. Despite the explicit deny, the attacker can still access the protected resources because the ACL check only evaluates allow entries
4. The attacker gains unauthorized access to sensitive EHR data, administrative functions, or other protected areas

This is a network-accessible vulnerability requiring low privileges and no user interaction, making it exploitable by authenticated users who should have had their access revoked.

  * @link      https://www.open-emr.org
  * @author    Rod Roark <rod@sunsetsystems.com>
  * @author    Brady Miller <brady.g.miller@gmail.com>
+ * @author    Michael A. Smith <michael@opencoreemr.com>
  * @copyright Copyright (c) 2020 Brady Miller <brady.g.miller@gmail.com>
+ * @copyright Copyright (c) 2026 OpenCoreEMR Inc <https://opencoreemr.com/>
  * @license   https://github.com/openemr/openemr/blob/master/LICENSE GNU General Public License 3
  */
 
 namespace OpenEMR\Common\Acl;
 
+use OpenEMR\Common\Database\QueryUtils;
 use OpenEMR\Gacl\Gacl;
 use OpenEMR\Common\Session\SessionWrapperFactory;

Source: GitHub Commit Update

The patch introduces proper query utilities to evaluate both allow and deny entries during permission checks.

Detection Methods for CVE-2026-33302

Indicators of Compromise

• Unexpected access to patient records or administrative functions by users who should have revoked permissions
• Audit log entries showing resource access by users with explicit deny ACL entries
• Discrepancies between configured deny rules and actual access patterns in application logs
• User accounts accessing resources after administrators have attempted to revoke their access

Detection Strategies

• Review OpenEMR access logs for users accessing resources they should be denied from based on ACL configuration
• Compare ACL deny configurations against actual access patterns to identify bypass attempts
• Implement additional logging at the ACL layer to track both allow and deny evaluation results
• Audit user group memberships to identify potential bypass paths through group inheritance

Monitoring Recommendations

• Enable comprehensive audit logging for all ACL-protected resource access in OpenEMR
• Implement alerts for access patterns that conflict with explicit deny configurations
• Regularly audit ACL configurations and compare against observed access behavior
• Monitor for unusual access to sensitive PHI by users with mixed allow/deny permissions

How to Mitigate CVE-2026-33302

Immediate Actions Required

• Upgrade OpenEMR to version 8.0.0.2 or later immediately
• Audit all ACL configurations to identify users or groups with explicit deny entries that may have been bypassed
• Review access logs to determine if any unauthorized access occurred prior to patching
• Consider temporarily removing users from allow groups rather than relying on deny entries until patched

Patch Information

Version 8.0.0.2 of OpenEMR addresses this vulnerability by implementing proper deny rule evaluation in the AclMain::zhAclCheck() function. The fix introduces QueryUtils for proper database queries that evaluate both allow and deny entries during authorization decisions. Administrators should upgrade immediately by following the official OpenEMR upgrade documentation. The security patch is available via the GitHub commit and detailed in the GitHub Security Advisory.

Workarounds

• Remove users from groups with allow permissions rather than adding deny entries for access revocation
• Implement network-level access controls to restrict access to sensitive resources pending upgrade
• Consider disabling affected user accounts entirely until the patch can be applied
• Implement additional authentication layers for access to critical patient data

# Verify current OpenEMR version
grep -r "v_major\|v_minor\|v_patch" /var/www/html/openemr/version.php

# Check for users with explicit deny entries that may be bypassed
mysql -u openemr -p openemr_db -e "SELECT * FROM gacl_aco WHERE value='0';"

# Backup before upgrade
tar -czvf openemr_backup_$(date +%Y%m%d).tar.gz /var/www/html/openemr/
mysqldump -u openemr -p openemr_db > openemr_db_backup_$(date +%Y%m%d).sql