CVE-2026-24896
Received Received - Intake
Broken Access Control in OpenEMR edih_main.php Exposes Logs

Publication date: 2026-02-25

Last updated on: 2026-02-25

Assigner: GitHub, Inc.

Description
OpenEMR is a free and open source electronic health records and medical practice management application. Prior to version 8.0.0, a Broken Access Control vulnerability exists in OpenEMR’s edih_main.php endpoint, which allows any authenticated user—including low-privilege roles like Receptionist—to access EDI log files by manipulating the log_select parameter in a GET request. The back-end fails to enforce role-based access control (RBAC), allowing sensitive system logs to be accessed outside the GUI-enforced permission boundaries. Version 8.0.0 fixes the issue.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-02-25
Last Modified
2026-02-25
Generated
2026-05-07
AI Q&A
2026-02-25
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
open-emr openemr to 8.0.0 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-284 The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

[{'type': 'paragraph', 'content': 'CVE-2026-24896 is a Broken Access Control vulnerability in OpenEMR versions prior to 8.0.0 affecting the edih_main.php endpoint.'}, {'type': 'paragraph', 'content': 'This vulnerability allows any authenticated user, including those with low-privilege roles like Receptionist, to access sensitive Electronic Data Interchange (EDI) log files by manipulating the "log_select" parameter in a GET request.'}, {'type': 'paragraph', 'content': 'The backend fails to enforce role-based access control (RBAC), meaning it does not properly check user permissions before granting access to these logs, allowing unauthorized users to bypass GUI-enforced permission boundaries.'}, {'type': 'paragraph', 'content': 'Technically, the code only verifies the CSRF token but does not check if the user has the required permissions to view the logs.'}] [2]


How can this vulnerability impact me? :

This vulnerability can lead to unauthorized disclosure of sensitive system logs and protected health information (PHI).

  • Attackers with low-privilege accounts can access internal EDI log files that should be restricted.
  • Exposure of system metadata and logs can enable further attacks such as control number spoofing.
  • It allows bypassing of auditing controls, potentially undermining system security monitoring.

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 attempting to access the edih_main.php endpoint with a low-privilege authenticated user account and manipulating the log_select parameter in a GET request to retrieve EDI log files.'}, {'type': 'paragraph', 'content': 'A practical detection method is to send an HTTP GET request to the vulnerable endpoint with a valid CSRF token and a specified log file name in the log_select parameter, then observe if the server returns the contents of the log file without proper permission checks.'}, {'type': 'list_item', 'content': 'Use curl or similar tools to send a crafted request, for example:'}, {'type': 'list_item', 'content': 'curl -b cookies.txt "https://<openemr-server>/openemr/interface/billing/edih_main.php?log_select=<logfilename>&csrf_token_form=<valid_csrf_token>"'}, {'type': 'list_item', 'content': 'Replace <logfilename> with a known log file name and <valid_csrf_token> with a valid CSRF token obtained from the authenticated session.'}, {'type': 'paragraph', 'content': 'If the response contains the contents of the log file despite the user having low privileges, the vulnerability is present.'}] [2]


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 this vulnerability has been fixed by enforcing proper access control on the edih_main.php endpoint.

If upgrading immediately is not possible, restrict access to the edih_main.php endpoint to only trusted users or roles with appropriate permissions by implementing network-level controls or web server access restrictions.

Additionally, monitor and audit access logs for any unauthorized attempts to access EDI log files.

The fix involves adding ACL checks to verify user permissions before allowing access to the logs, returning HTTP 403 Forbidden if the user lacks permission.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart