CVE-2026-34053: 
OpenEMR vulnerability analysis and mitigation

CVE-2026-34053 is a missing authorization vulnerability in OpenEMR's AJAX procedure order deletion endpoint (interface/forms/procedure_order/handle_deletions.php) that allows any authenticated user, regardless of role, to irreversibly delete procedure orders, answers, and specimens belonging to any patient in the system. It affects all OpenEMR versions prior to 8.0.0.3 (including versions up to and including 8.0.0.1). The vulnerability was disclosed on March 25–26, 2026, with a patch released the same day in version 8.0.0.3. It carries a CVSS v3.1 base score of 8.1 (High) per NVD, or 7.1 (High) per the GitHub Security Advisory (GitHub Advisory, Red Hat CVE).

The root cause is CWE-862 (Missing Authorization): the endpoint handle_deletions.php validates the CSRF token and requires an authenticated session via globals.php, but performs no role-based access control — there is no AclMain::aclCheckCore() call, no validation that the supplied order_id or specimen_id belongs to the current patient session, and no reference to $pid or $encounter (GitHub Advisory). The deleteProcedure() function takes order_id and order_seq directly from POST data and executes hard DELETE statements against procedure_answers and procedure_order_code, plus a soft delete on procedure_specimen. Because procedure_order_id and procedure_specimen_id are sequential AUTO_INCREMENT integers, an attacker can trivially enumerate and target records belonging to any patient. This is inconsistent with the sibling file delete.php in the same directory, which correctly enforces admin/super privileges before allowing analogous deletions (GitHub Advisory, Patch Commit).

Any authenticated OpenEMR user — including low-privilege accounts such as front-desk staff — can irreversibly destroy clinical procedure data (answers and order codes via hard DELETE) and soft-delete specimens for any patient in the system, constituting a cross-patient data integrity violation and privilege escalation. There is no confidentiality impact (no data is exposed to the attacker), but the integrity and availability impacts are high: missing procedure orders could disrupt patient care workflows, cause misdiagnosis, or result in repeated procedures in a clinical environment. The sequential integer primary keys make mass enumeration and bulk deletion of records across all patients trivially achievable (GitHub Advisory).

A concrete, step-by-step proof-of-concept is publicly available in the GitHub Security Advisory, demonstrating exploitation with a simple HTTP POST request (GitHub Advisory). The EPSS score is approximately 0.034% (0.000340), indicating low current probability of automated exploitation. There is no evidence of in-the-wild exploitation at this time, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported.

1. Authenticate: Log in to the target OpenEMR instance as any user with minimal privileges (e.g., a front-desk account with no clinical or admin permissions).
2. Obtain a valid CSRF token: Navigate to any OpenEMR page and extract the csrf_token_form value from the page source or by intercepting network requests using a browser's developer tools or a proxy such as Burp Suite.
3. Identify target records: Since procedure_order_id and procedure_specimen_id are sequential AUTO_INCREMENT integers, begin enumeration from order_id=1 and increment to identify valid records across all patients.
4. Send deletion request: Issue a POST request directly to the vulnerable endpoint to delete a procedure belonging to any patient:

POST /interface/forms/procedure_order/handle_deletions.php
Content-Type: application/x-www-form-urlencoded

action=delete_procedure&order_id=1&order_seq=1&csrf_token_form=<valid_token>

5. Observe impact: Confirm that procedure_answers and procedure_order_code rows for the specified order_id/order_seq are hard-deleted and associated specimens are soft-deleted, regardless of which patient they belong to.
6. Enumerate and repeat: Increment order_id to target additional patients' records. Repeat with action=delete_specimen&specimen_id=<id> to soft-delete arbitrary specimens across the system (GitHub Advisory).

• Network: Unusual or repeated HTTP POST requests to /interface/forms/procedure_order/handle_deletions.php from user accounts that do not normally interact with procedure order management; requests originating from unexpected IP addresses or at unusual hours.
• Logs: Web server access logs showing sequential order_id values in POST bodies to handle_deletions.php from a single authenticated session; audit logs recording mass deletions of procedure records attributed to a low-privilege user account.
• Database: Sudden absence of rows in procedure_answers and procedure_order_code tables across multiple patients; procedure_specimen rows with deleted=1 and updated_by set to an unexpected user ID; procedure_order rows with activity=0 for orders not clinically closed.
• Application: OpenEMR audit trail entries showing delete_procedure or delete_specimen actions performed by users without clinical or administrative roles (GitHub Advisory).

Upgrade OpenEMR to version 8.0.0.3 or later, which patches this issue by adding an AclMain::aclCheckCore('admin', 'super') check to handle_deletions.php, consistent with the sibling delete.php endpoint (OpenEMR Release, Patch Commit). For systems unable to patch immediately, implement network-level access controls (e.g., WAF rules or firewall policies) to restrict direct POST access to interface/forms/procedure_order/handle_deletions.php for non-administrative users, and enable audit logging to monitor for suspicious deletion activity (Red Hat CVE).

The vulnerability was part of a broader set of 18 security fixes (including multiple High-severity issues) released in OpenEMR 8.0.0.3 on March 25, 2026, indicating a significant security audit effort by the OpenEMR team (OpenEMR Release). A blog post from Aisle noted the discovery of 38 critical security vulnerabilities in healthcare software used by 100,000 providers, suggesting this CVE may be part of a coordinated research disclosure (Aisle Blog). Credit for discovery was given to researchers pavelkohout396 (reporter), simecek (analyst), and kojiromike (remediation developer) (GitHub Advisory).