CVE-2026-33910: 
OpenEMR vulnerability analysis and mitigation

CVE-2026-33910 is a SQL injection vulnerability in OpenEMR's patient selection feature affecting all versions up to and including 8.0.0.2. The flaw allows authenticated attackers to inject arbitrary SQL commands by exploiting insufficient input validation in library/patient.inc.php. It was disclosed on March 25, 2026, with a patch released the same day in version 8.0.0.3. The vulnerability carries a CVSS v3.1 base score of 8.8 (High) per NVD/Feedly data, though the GitHub Security Advisory scores it at 7.2 (High) using a higher privileges-required metric (GitHub Advisory, Feedly).

The root cause is CWE-89 (Improper Neutralization of Special Elements used in an SQL Command). In the getByPatientDemographics() function in library/patient.inc.php (around line 689), field IDs retrieved from the layout_options table are directly concatenated into a dynamically constructed SQL WHERE clause using add_escape_custom() — a function designed for SQL values, not SQL identifiers — without proper parameterization. An attacker first inserts a malicious payload (e.g., 1 OR 1=1 or injection'payload) into the layout_options.field_id column via /interface/super/edit_layout.php, then triggers the injection by accessing /interface/main/finder/patient_select.php, causing the stored payload to be embedded unsanitized into the executed SQL query (GitHub Advisory, Patch Commit).

Successful exploitation allows an authenticated attacker to read sensitive patient health information from the database, modify or delete medical records, and potentially execute operating system commands depending on the database server configuration. Given that OpenEMR stores protected health information (PHI) including demographics, diagnoses, and treatment records, a breach could result in significant HIPAA violations and patient data exposure. The vulnerability affects confidentiality, integrity, and availability at a high level, with potential for full database compromise (GitHub Advisory, Feedly).

Public proof-of-concept (PoC) exploit code is available on GitHub, including a repository with detailed step-by-step curl commands demonstrating the full attack chain against a live OpenEMR instance (PoC Repository). The GitHub Security Advisory itself also contains concrete PoC curl commands (GitHub Advisory). As of the time of reporting, there is no confirmed evidence of in-the-wild exploitation, and the vulnerability is not listed in the CISA KEV catalog. The EPSS score is approximately 0.027% (0.000270), indicating a currently low probability of exploitation in the wild (Feedly). The vulnerability was discovered by researcher Christophe SUBLET of Grenoble INP - Esisar, UGA.

1. Authenticate: Log in to the OpenEMR instance with an account that has administrative (admin/super) ACL privileges, sufficient to access /interface/super/edit_layout.php.
2. Obtain CSRF token: Retrieve a valid csrf_token_form value from the OpenEMR session, required for form submissions.
3. Inject payload into layout_options: Send a crafted HTTP POST request to /interface/super/edit_layout.php with formaction=addfield, layout_id=DEM, and a malicious newid value (e.g., newid=1 OR 1=1 or newid=injection'payload). This inserts the payload as a field_id into the layout_options table:

curl -X POST "http://<target>/interface/super/edit_layout.php" \
  -H "Cookie: OpenEMR=<session_cookie>" \
  --data-urlencode "formaction=addfield" \
  --data-urlencode "layout_id=DEM" \
  --data-urlencode "csrf_token_form=<token>" \
  --data-urlencode "newid=1 OR 1=1" \
  --data-urlencode "newtitle=Test Field" \
  --data-urlencode "newuor=1"

4. Trigger the SQL injection: Access the patient selection endpoint, which reads field_id values from layout_options and concatenates them unsanitized into a SQL query:

curl -k -b "OpenEMR=<session_cookie>" \
  'http://<target>/interface/main/finder/patient_select.php?from_page=&report_id=0&csrf_token_form=<token>&findBy=Any'

5. Observe results: The injected SQL (e.g., WHERE 1 OR 1=1 like ?) alters query logic, potentially returning all patient records or causing errors that reveal database structure, enabling further data extraction or manipulation (GitHub Advisory, PoC Repository).

• Network: Unusual HTTP POST requests to /interface/super/edit_layout.php with formaction=addfield and suspicious newid values containing SQL keywords (e.g., OR, UNION, SELECT, quotes); HTTP GET requests to /interface/main/finder/patient_select.php shortly after layout modification activity.
• Logs: OpenEMR application logs showing SQL errors referencing patient_select.php at line 271 or patient.inc.php at line 685; error messages containing SQL Statement failed on preparation or Query Error with unexpected SQL fragments in the WHERE clause.
• Database: Unexpected entries in the layout_options table with form_id='DEM' and field_id values containing SQL syntax characters (e.g., spaces, quotes, OR, =); audit log entries showing layout field additions by non-administrative users.
• File System: No specific file artifacts expected for this SQL injection vector, but web shells or unexpected files in the OpenEMR web root may indicate post-exploitation activity (GitHub Advisory).

Upgrade OpenEMR to version 8.0.0.3 or later, which was released on March 25, 2026, and contains the security fix (OpenEMR Release). The patch replaces unsafe add_escape_custom() string concatenation in library/patient.inc.php with parameterized queries via QueryUtils::sqlInsert() and QueryUtils::sqlStatementThrowException(), and hardens column name escaping using escape_sql_column_name() (Patch Commit). As interim mitigations, restrict network access to OpenEMR to trusted users only, enforce least-privilege database user permissions to limit the impact of SQL injection, and audit the layout_options table for suspicious field_id entries.

The vulnerability was reported by researcher Christophe SUBLET of Grenoble INP - Esisar, UGA as part of the CyberSkills/Orion project, and remediated by OpenEMR developer kojiromike (GitHub Advisory). The OpenEMR project responded promptly, releasing the patch on the same day as disclosure (March 25, 2026) and including it among numerous other security fixes in the v8.0.0.3 release (OpenEMR Release). No significant broader media coverage or notable social media reactions have been identified beyond standard vulnerability database aggregation.