CVE-2026-33909: 
OpenEMR vulnerability analysis and mitigation

CVE-2026-33909 is a SQL injection vulnerability in OpenEMR's MedEx recall/reminder processing code, classified as Moderate severity. It affects all OpenEMR versions prior to 8.0.0.3 (i.e., <= 8.0.0.2). The vulnerability was disclosed on March 25, 2026, with a patch released the same day in version 8.0.0.3. It carries a CVSS v3.1 base score of 5.9 (Medium) (GitHub Advisory, Feedly).

The root cause is CWE-89 (Improper Neutralization of Special Elements used in an SQL Command), arising from multiple variables in library/MedEx/API.php being concatenated directly into SQL queries without parameterization or type casting. Two distinct injection vectors exist: (1) a second-order injection where $prefs['ME_facilities'] is read from the medex_prefs table and inserted into an IN() clause — the value originates from $_REQUEST['facilities'] in interface/main/messages/save.php stored without integer validation; and (2) injection via external MedEx API responses, where $event['E_fire_time'] is concatenated into an INTERVAL clause without an (int) cast in the RECALL path, $event['T_appt_stats'] values are joined into an IN() clause without quoting, and $event['timing'] and a loop variable from $event['appt_stats'] are concatenated into INTERVAL and LIMIT clauses without casting. Exploitation requires MedEx to be explicitly enabled (disabled by default), and either admin-level access to MedEx preferences (Vector 1) or compromise of the MedEx API account or a MITM attack on the API connection (Vector 2) (GitHub Advisory, Patch Commit).

Successful exploitation allows an attacker to execute arbitrary SQL queries against the OpenEMR database, potentially reading or modifying sensitive patient records including electronic health records (EHRs). The confidentiality and integrity of patient data are both at high risk, while availability is not directly impacted. Given OpenEMR's role as a healthcare management platform, unauthorized access to or modification of patient records could have serious regulatory (HIPAA) and patient safety implications (GitHub Advisory, Feedly).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the time of disclosure (Feedly). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.023%, reflecting a low probability of near-term exploitation. Exploitation is further constrained by the requirement that MedEx be enabled and that the attacker possess high privileges or the ability to perform a MITM attack on the MedEx API connection (GitHub Advisory).

1. Prerequisite — Enable MedEx: Confirm that MedEx is enabled on the target OpenEMR instance (it is disabled by default). This feature must be active for the vulnerable code paths to execute.
2. Vector 1 — Second-Order Injection via Admin Preferences: Authenticate as an administrator, navigate to MedEx preferences in interface/main/messages/save.php, and submit a crafted facilities parameter containing SQL injection payloads (e.g., 1 UNION SELECT ...). These values are stored in the medex_prefs table without integer validation and later concatenated into an IN() clause when generate() is called.
3. Vector 2 — MedEx API Response Injection: Compromise the MedEx API account or perform a MITM attack on the API connection. Craft a malicious API response where fields such as E_fire_time, T_appt_stats, timing, or loop variables from appt_stats contain SQL injection payloads (e.g., unsanitized strings in INTERVAL or LIMIT clauses).
4. Trigger SQL Execution: Cause the generate() method in library/MedEx/API.php to execute by initiating a MedEx recall or reminder processing cycle, which will incorporate the injected values into live SQL queries.
5. Extract or Modify Data: Use the injected SQL to read sensitive patient records from the OpenEMR database (e.g., via UNION SELECT to exfiltrate data) or modify records (e.g., via stacked queries if supported by the database configuration) (GitHub Advisory, Patch Commit).

• Logs: Unusual or malformed SQL errors in OpenEMR application logs related to MedEx/API.php or generate() method execution; unexpected SQL syntax errors referencing INTERVAL, LIMIT, or IN() clauses in database logs.
• Database: Unexpected queries containing UNION SELECT, unusual IN() clause values with non-integer entries, or anomalous INTERVAL/LIMIT values in database query logs; unauthorized reads or modifications to patient records in patient_data, medex_recalls, or openemr_postcalendar_events tables.
• Application: Unexpected changes to MedEx preferences in the medex_prefs table, particularly the ME_facilities field containing non-integer or pipe-delimited values with SQL syntax.
• Network: Anomalous or tampered responses from the external MedEx API endpoint, particularly in fields E_fire_time, T_appt_stats, timing, or appt_stats containing non-numeric or SQL-like strings (GitHub Advisory).

Upgrade OpenEMR to version 8.0.0.3 or later, which contains the patch addressing this vulnerability (OpenEMR Release). The fix applies FILTER_VALIDATE_INT to the facilities and providers inputs in save.php, replaces direct concatenation with parameterized placeholders for T_appt_stats, validates E_fire_time with integer filtering in the RECALL path, and applies filter_var with integer validation to timing and loop variables in API.php (Patch Commit). As interim mitigations, disable the MedEx feature if not in use, restrict administrative account access to authorized personnel only, implement network segmentation to limit access to OpenEMR instances, and monitor database activity for suspicious SQL patterns.