CVE-2026-33909
SQL Injection in OpenEMR MedEx Module Enables Data Manipulation
Publication date: 2026-03-25
Last updated on: 2026-03-26
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| open-emr | openemr | to 8.0.0.3 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-89 | The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data. |
Attack-Flow Graph
AI Powered Q&A
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability involves SQL injection in the MedEx recall/reminder processing component of OpenEMR versions prior to 8.0.0.3. Detection involves identifying if your OpenEMR instance is running a vulnerable version and if the MedEx module is enabled.
To detect potential exploitation or presence of this vulnerability on your system, you can:
- Check the OpenEMR version to confirm if it is older than 8.0.0.3.
- Verify if the MedEx module is enabled, as it is disabled by default.
- Review database entries in the medex_prefs table for suspicious or malformed values in the ME_facilities preference, which could indicate injection attempts.
- Monitor logs or network traffic for unusual SQL queries or unexpected API calls to the MedEx API that might indicate injection attempts or MITM attacks.
Specific commands or queries you might use include:
- SQL query to check OpenEMR version: SELECT version(); or check application version files.
- SQL query to inspect medex_prefs table for suspicious ME_facilities values: SELECT * FROM medex_prefs WHERE ME_facilities LIKE '%|%' OR ME_facilities REGEXP '[^0-9,]';
- Use network monitoring tools (e.g., tcpdump, Wireshark) to capture traffic to the MedEx API endpoint and analyze for suspicious payloads.
- Check application logs for errors or warnings related to MedEx processing or SQL errors indicating injection attempts.
Can you explain this vulnerability to me?
This vulnerability exists in OpenEMR versions prior to 8.0.0.3 where several variables in the MedEx recall/reminder processing code are concatenated directly into SQL queries without proper parameterization or type casting.
This improper handling enables SQL injection attacks, allowing an attacker to manipulate the SQL queries executed by the application.
The issue was fixed in version 8.0.0.3 by applying a patch.
How can this vulnerability impact me? :
This SQL injection vulnerability can have serious impacts including unauthorized access to sensitive data, data manipulation, and potential compromise of the integrity of the medical records managed by OpenEMR.
Given the CVSS score of 5.9 with high confidentiality and integrity impact, an attacker with high privileges could exploit this vulnerability to read or alter sensitive patient information.
What immediate steps should I take to mitigate this vulnerability?
To mitigate this vulnerability, you should upgrade OpenEMR to version 8.0.0.3 or later, as this version contains a patch that fixes the SQL injection issue.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
CVE-2026-33909 is a moderate severity SQL injection vulnerability in OpenEMR that allows attackers with certain privileges to execute arbitrary SQL commands, potentially reading or modifying sensitive patient records.
Because OpenEMR is an electronic health records system, unauthorized access or modification of patient data due to this vulnerability could lead to violations of data protection regulations such as HIPAA and GDPR, which mandate the confidentiality and integrity of personal health information.
The vulnerability arises from improper input validation and lack of parameterization in SQL queries, which could be exploited to compromise sensitive health data, thereby impacting compliance with these standards.