CVE-2026-32120: OpenEMR Auth Bypass Vulnerability

CVE-2026-32120 Overview

CVE-2026-32120 is an Insecure Direct Object Reference (IDOR) vulnerability affecting OpenEMR, a widely-used free and open source electronic health records (EHR) and medical practice management application. The vulnerability exists in the fee sheet product save logic within library/FeeSheet.class.php, allowing any authenticated user with fee sheet ACL access to delete, modify, or read drug_sales records belonging to arbitrary patients by manipulating the hidden prod[][sale_id] form field.

Critical Impact

Authenticated attackers can access, modify, or delete sensitive patient drug sales records across the entire OpenEMR installation, potentially compromising patient privacy and medical record integrity.

Affected Products

• OpenEMR versions prior to 8.0.0.3
• OpenEMR installations with fee sheet ACL access enabled
• Healthcare organizations using vulnerable OpenEMR deployments

Discovery Timeline

• 2026-03-25 - CVE-2026-32120 published to NVD
• 2026-03-26 - Last updated in NVD database

Technical Details for CVE-2026-32120

Vulnerability Analysis

This IDOR vulnerability stems from insufficient authorization checks in OpenEMR's fee sheet functionality. The save() method in library/FeeSheet.class.php accepts user-supplied sale_id values through a hidden form field (prod[][sale_id]) and uses these values directly in five SQL queries—including SELECT, UPDATE, and DELETE operations—without verifying that the referenced record belongs to the current patient and encounter context.

The vulnerability allows horizontal privilege escalation, where an authenticated user can access data belonging to other patients. This is particularly concerning in healthcare environments where patient data confidentiality is paramount and protected under regulations such as HIPAA.

Root Cause

The root cause of this vulnerability is the lack of proper authorization validation before performing database operations on drug_sales records. The application trusts user-supplied sale_id parameters without verifying ownership or access permissions, violating the principle of least privilege and failing to implement proper access control checks.

This represents a classic IDOR pattern where object references (in this case, sale_id values) are exposed to users and used without proper authorization verification. The application assumes that if a user can submit a form, they should have access to any record ID they provide.

Attack Vector

An attacker with valid credentials and fee sheet ACL access can exploit this vulnerability through the following attack vector:

1. The attacker authenticates to the OpenEMR application with legitimate credentials that have fee sheet access
2. When accessing the fee sheet functionality, the attacker intercepts or modifies the form submission
3. By manipulating the hidden prod[][sale_id] form field value, the attacker can reference drug_sales records belonging to other patients
4. The vulnerable save() method processes these modified values in SQL queries without authorization checks
5. The attacker can read sensitive drug sales information, modify existing records, or delete records entirely

The attack requires network access and valid authentication but has low complexity once these prerequisites are met. The vulnerability affects confidentiality, integrity, and availability of patient drug sales data.

Detection Methods for CVE-2026-32120

Indicators of Compromise

• Unusual access patterns to fee sheet functionality from a single user account accessing multiple patient records
• Database audit logs showing SELECT, UPDATE, or DELETE operations on drug_sales table with patient IDs inconsistent with the authenticated user's assigned patients
• Web application logs showing manipulation of prod[][sale_id] parameters with sequential or enumerated values
• Unexpected modifications or deletions in drug_sales records without corresponding clinical workflow

Detection Strategies

• Implement database query monitoring to detect cross-patient data access patterns in the drug_sales table
• Deploy web application firewall (WAF) rules to detect parameter tampering on fee sheet form submissions
• Enable detailed audit logging for all fee sheet operations including the patient context and user session
• Monitor for anomalous API request patterns where sale_id values don't correlate with the patient encounter context

Monitoring Recommendations

• Configure alerting for any user accessing drug_sales records across multiple patient IDs in a short timeframe
• Implement real-time monitoring of fee sheet database operations with correlation to user permissions
• Review access logs regularly for patterns indicating enumeration or brute-force attempts on sale_id values

How to Mitigate CVE-2026-32120

Immediate Actions Required

• Upgrade OpenEMR to version 8.0.0.3 or later immediately
• Review database audit logs for any signs of unauthorized access to drug_sales records
• Temporarily restrict fee sheet ACL access to only essential personnel until patching is complete
• Implement additional network segmentation to limit exposure of the OpenEMR application

Patch Information

OpenEMR has released version 8.0.0.3 which contains a patch for this vulnerability. The fix implements proper authorization checks to verify that the sale_id being operated on belongs to the current patient and encounter before executing any SQL queries. Organizations should upgrade to this version as the primary remediation.

For detailed patch information, refer to the GitHub Commit Update and the GitHub Security Advisory GHSA-pvvj-mv7h-7847. The patched release is available at GitHub Release v8.0.0.3.

Workarounds

• Restrict fee sheet ACL access to the minimum number of users required for clinical operations
• Implement network-level access controls to limit which IP addresses can access the OpenEMR application
• Deploy a web application firewall with custom rules to validate that sale_id parameters correspond to the current patient session
• Enable comprehensive database audit logging to detect and investigate any unauthorized access attempts

# Configuration example - Restrict access to OpenEMR at the web server level
# Apache configuration to limit access by IP range
<Directory /var/www/openemr>
    # Restrict to internal network only
    Require ip 10.0.0.0/8
    Require ip 192.168.0.0/16
    # Deny all other access
    Require all denied
</Directory>