CVE-2026-25927: 
OpenEMR vulnerability analysis and mitigation

CVE-2026-25927 is an Insecure Direct Object Reference (IDOR) / authorization bypass vulnerability in OpenEMR's DICOM viewer state API that allows authenticated users to read or modify DICOM viewer state (e.g., annotations, view settings) for any document by enumerating document IDs. It affects all OpenEMR versions prior to 8.0.0 and was disclosed on February 25, 2026. The vulnerability carries a CVSS v3.1 base score of 7.1 (High) (GitHub Advisory, Red Hat CVE).

The root cause is an Authorization Bypass Through User-Controlled Key (CWE-639), specifically an IDOR flaw in the DICOM viewer state API located in controllers/C_Document.class.php. The view_action() and retrieve_action() methods accept a doc_id parameter directly from the request and load the corresponding document without verifying that the document's patient (via Document::get_foreign_id()) matches the requesting user's authorized patient or encounter. The Document::can_access() method only checks category ACO permissions and does not bind the document to the requested patient, meaning any authenticated user with access to the DICOM viewer endpoint can supply an arbitrary doc_id to access or tamper with another patient's imaging data. A proof-of-concept is publicly documented in the GitHub Security Advisory (GitHub Advisory).

Successful exploitation allows an authenticated attacker to read or modify DICOM viewer state — including annotations and view settings — for any document in the system, constituting unauthorized access to Protected Health Information (PHI) and sensitive medical imaging metadata. The confidentiality impact is rated High, as an attacker can enumerate document IDs to access records belonging to any patient across the entire OpenEMR deployment. Integrity is also affected (rated Low), as an attacker can corrupt or alter DICOM annotations and settings for documents they are not authorized to access. Availability is not impacted (GitHub Advisory).

A proof-of-concept exploit is publicly documented in the GitHub Security Advisory, demonstrating exploitation via simple HTTP GET/POST requests with enumerated doc_id values. There is no evidence of active in-the-wild exploitation at this time. The EPSS score is approximately 0.028% (0.000280), indicating a low probability of exploitation in the near term. The vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog (GitHub Advisory, Feedly).

1. Reconnaissance: Identify an OpenEMR instance running a version prior to 8.0.0 that has the DICOM viewer feature enabled and is accessible over the network.
2. Authentication: Log in as any authenticated user who has document or imaging permissions within the OpenEMR application.
3. Obtain a baseline document ID: Access a DICOM document belonging to an authorized patient to observe the doc_id format (e.g., doc_id=100).
4. Enumerate document IDs: Systematically increment or vary the doc_id parameter to reference documents belonging to other patients (e.g., doc_id=101, doc_id=300).
5. Read unauthorized state: Send a crafted GET request to the DICOM viewer state API: GET /controller.php?document&view&patient_id=1&doc_id=300 HTTP/1.1 with a valid session cookie. If the server returns state data for the target document, the IDOR is confirmed.
6. Modify unauthorized state: Send a POST request to the state save endpoint with the target doc_id to overwrite or corrupt annotations and view settings for another patient's DICOM study.
7. Exfiltrate PHI: Collect returned DICOM viewer state data, which may include imaging metadata, annotations, and other Protected Health Information (GitHub Advisory).

• Network: Unusual HTTP GET or POST requests to /controller.php?document&view with varying doc_id values in rapid succession, particularly where patient_id does not correspond to the doc_id being requested; sequential or enumerated doc_id values in web server access logs.
• Logs: OpenEMR access logs showing a single authenticated user account accessing DICOM viewer state endpoints for a large number of distinct doc_id values across different patients; repeated 200 OK responses to DICOM state API requests from a single session.
• Application Behavior: DICOM annotations or view settings for patient records being modified without corresponding clinical activity; discrepancies between audit logs and expected user-patient access patterns (GitHub Advisory).

OpenEMR version 8.0.0 resolves this vulnerability by implementing proper authorization checks that verify the requested doc_id belongs to the current user's authorized patient or encounter before reading or writing state. All deployments running OpenEMR versions prior to 8.0.0 should upgrade to version 8.0.0 or later immediately, given the sensitivity of electronic health records and the high confidentiality impact. No configuration-based workaround is documented; upgrading is the only recommended remediation (GitHub Advisory).

The vulnerability was reported by security researchers identified as simecek (reporter) and pavelkohout396 (analyst), with remediation credited to kojiromike, and was published by OpenEMR maintainer bradymiller via GitHub Security Advisories. An Aisle security blog post noted the discovery of 38 critical security vulnerabilities in healthcare software used by 100,000 providers, which may include this finding (Aisle Blog). No significant broader media coverage or social media reactions have been identified at this time.