CVE-2026-24908
SQL Injection in OpenEMR Patient API Risks PHI Exposure
Publication date: 2026-02-25
Last updated on: 2026-02-27
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 (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
Can you explain this vulnerability to me?
CVE-2026-24908 is a critical SQL injection vulnerability in the OpenEMR Patient REST API endpoint affecting versions prior to 8.0.0. The vulnerability arises because the `_sort` parameter, which specifies sorting fields in database queries, is not properly validated or escaped before being used in SQL ORDER BY clauses.
Authenticated users with API access can exploit this flaw by injecting arbitrary SQL commands through the `_sort` parameter. This happens because the application directly concatenates user-supplied sort field names into SQL queries without proper input validation or escaping.
Exploitation can lead to unauthorized database access, exposure of Protected Health Information (PHI), and credential compromise. The issue is fixed in OpenEMR version 8.0.0 by implementing whitelist validation of allowed sort columns and proper escaping.
How can this vulnerability impact me? :
This vulnerability can have severe impacts including unauthorized access to the database, exposure of sensitive Protected Health Information (PHI), and compromise of user credentials.
- Attackers with authenticated API access can execute arbitrary SQL queries.
- Confidentiality, integrity, and availability of the system are all at high risk.
- Healthcare organizations using OpenEMR and their patients are the affected parties.
Because the vulnerability allows attackers to manipulate database queries, it can lead to data breaches, unauthorized data modification, and potential service disruption.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
[{'type': 'paragraph', 'content': 'This vulnerability can be detected by testing the Patient REST API endpoint for SQL injection via the `_sort` parameter. An authenticated user with API access can attempt to inject SQL commands through this parameter to observe if the system is vulnerable.'}, {'type': 'paragraph', 'content': 'Example commands to detect the vulnerability include using curl to send specially crafted requests that exploit the SQL injection flaw:'}, {'type': 'list_item', 'content': 'Induce a delay to confirm SQL injection: curl -X GET "https://target-openemr.com/apis/api/patient?_sort=uuid,(SELECT SLEEP(5))--" -H "Authorization: Bearer YOUR_ACCESS_TOKEN"'}, {'type': 'list_item', 'content': 'Extract data to confirm unauthorized access: curl -X GET "https://target-openemr.com/apis/api/patient?_sort=uuid,(SELECT username FROM users WHERE id=1 LIMIT 1)--" -H "Authorization: Bearer YOUR_ACCESS_TOKEN"'}, {'type': 'paragraph', 'content': 'These commands require a valid OAuth2 bearer token and access to the OpenEMR REST API.'}] [1]
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation step is to upgrade OpenEMR to version 8.0.0 or later, where the vulnerability has been fixed.
The fix involves validating the `_sort` parameter against a whitelist of allowed column names before including them in SQL queries, preventing SQL injection.
If upgrading immediately is not possible, restrict API access to trusted users only and monitor API usage closely to detect suspicious activity.
Applying the patch that introduces whitelist validation in the `buildSortOrderClauseFromConfig()` method and uses the `ALLOWED_SORT_COLUMNS` constant to filter sort fields is the recommended technical mitigation.