CVE-2026-32120: 
OpenEMR vulnerability analysis and mitigation

CVE-2026-32120 is an Insecure Direct Object Reference (IDOR) vulnerability in OpenEMR's fee sheet product save logic that allows any authenticated user with fee sheet ACL access to delete, modify, or read drug_sales records belonging to arbitrary patients. The flaw resides in library/FeeSheet.class.php and affects all OpenEMR versions prior to 8.0.0.3. It was disclosed on March 25, 2026, with a patch released the same day in version 8.0.0.3. The CVSS v3.1 base score is 6.3 (Medium) per NVD, while the GitHub Security Advisory assigns a score of 6.5 (Medium) (GitHub Advisory, OpenEMR Release).

The root cause is CWE-639 (Authorization Bypass Through User-Controlled Key): the save() method in library/FeeSheet.class.php accepts a sale_id directly from the client-submitted prod[][sale_id] hidden form field and uses it in five SQL queries (SELECT, UPDATE, DELETE) without appending AND pid = ? AND encounter = ? to verify record ownership. This contrasts with other methods in the same class (e.g., loadProductItems(), visitChecksum()) that correctly scope queries to the current patient and encounter. Because sale_id is an auto-increment integer, an attacker can enumerate values sequentially to target specific records across all patients. The fix, applied in commit c5b4dd8, adds AND pid = ? AND encounter = ? to all five affected SQL statements (GitHub Advisory, Patch Commit).

An authenticated attacker with fee sheet ACL access can delete another patient's drug_sales record (which also cascades to delete the associated prescription), modify drug sale fields such as quantity, fee, price level, and sale date, and corrupt drug inventory counts by triggering incorrect drug_inventory.on_hand adjustments against the wrong patient's dispensation. Critically, audit logging is also bypassed — logFSMessage() records the attacker's current patient context ($this->pid) rather than the victim's patient ID, making forensic detection difficult. This vulnerability directly threatens the confidentiality, integrity, and availability of sensitive protected health information (PHI) in a healthcare setting (GitHub Advisory).

A detailed proof-of-concept (PoC) is publicly available in the GitHub Security Advisory, providing step-by-step instructions for exploiting the vulnerability using browser DevTools to manipulate hidden form fields. No exploit kits or threat actor attribution have been identified, and there is no evidence of in-the-wild exploitation at this time. The EPSS score is approximately 0.025% (0.000250), indicating low current exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog (GitHub Advisory).

1. Authenticate: Log in to OpenEMR as any user account that has been granted fee sheet ACL access.
2. Identify a target record: Create or identify two patients — Patient A (attacker's context) and Patient B (victim). Open Patient B's encounter, navigate to the fee sheet, add a product line item, and save it. Note the sale_id assigned to this record (visible in the form's hidden fields or by querying the drug_sales table directly).
3. Open attacker's context: Navigate to Patient A's encounter and open the fee sheet. Add a product line item if none exists.
4. Manipulate the hidden form field: Using browser DevTools (e.g., Chrome Inspector), locate the hidden input field prod[N][sale_id] in the fee sheet form and replace its value with Patient B's sale_id.
5. Trigger the desired action:
   • Delete: Check the corresponding prod[N][del] checkbox (or set its hidden input to 1).
   • Modify: Change prod[N][price], prod[N][units], or other fields to desired values.
6. Submit the form: Click Save to submit the fee sheet form. The server-side save() method processes the manipulated sale_id without ownership verification.
7. Verify impact: Confirm in the drug_sales table (SELECT * FROM drug_sales WHERE sale_id = <target_id>) that Patient B's record has been deleted or modified. Note that audit logs will incorrectly attribute the action to Patient A's context (GitHub Advisory).

• Logs: Audit log entries in OpenEMR where logFSMessage() records fee sheet actions (e.g., 'Item deleted', 'Warehouse changed') attributed to one patient's PID but affecting drug_sales records belonging to a different patient's PID — detectable by cross-referencing log PID with the actual drug_sales.pid of the affected record.
• Database: Unexpected deletions or modifications in the drug_sales table where the pid of the affected record does not match the pid of the user's active session or the encounter context recorded in logs; cascading deletions in the prescriptions table without corresponding clinical workflow activity.
• Network: HTTP POST requests to the fee sheet save endpoint (e.g., interface/forms/fee_sheet/new.php) containing prod[][sale_id] values that do not correspond to records associated with the patient PID in the active session — detectable via WAF or application-layer logging of POST body parameters.
• Application: Anomalous drug_inventory.on_hand values inconsistent with recorded dispensation history for a given drug, indicating inventory corruption from cross-patient IDOR exploitation (GitHub Advisory).

The primary remediation is to upgrade OpenEMR to version 8.0.0.3 or later, which contains the patch applied in commit c5b4dd8 that adds AND pid = ? AND encounter = ? ownership checks to all five affected SQL statements in library/FeeSheet.class.php. No official configuration-based workaround is available; as an interim measure, administrators should restrict fee sheet ACL access to the minimum necessary personnel to reduce the attack surface. Organizations should also audit drug_sales records for unexpected modifications or deletions, particularly where audit log PIDs do not match affected record PIDs (Patch Commit, OpenEMR Release).

The vulnerability was reported by security researchers pavelkohout396 and simecek, with remediation development credited to kojiromike, and was published through GitHub's coordinated disclosure process. The advisory was noted in the context of a broader set of 38 security vulnerabilities discovered in OpenEMR, as referenced by Aisle's security research blog. No significant social media commentary or major media coverage specific to this CVE has been identified beyond standard vulnerability database aggregation (GitHub Advisory).