CVE-2026-25745: 
OpenEMR vulnerability analysis and mitigation

CVE-2026-25745 is an Insecure Direct Object Reference (IDOR) / Authorization Bypass vulnerability in OpenEMR, a widely used open-source electronic health records (EHR) and medical practice management application. Affecting all versions up to and including 8.0.0, the flaw allows an authenticated user with notes write permission to modify any patient's messages or notes by supplying an arbitrary message ID — without the server verifying patient ownership or user authorization scope. The vulnerability was published on March 18, 2026, and carries a CVSS v3.1 base score of 6.5 (Medium) (GitHub Advisory).

The root cause is CWE-639 (Authorization Bypass Through User-Controlled Key): the MessageService::update() method in src/Services/MessageService.php performed SQL queries using only the message/note ID (WHERE id = ?) without also filtering by the patient ID (pid). This means any authenticated user with notes write permission can supply an arbitrary note ID belonging to a different patient, and the server will apply the update without verifying patient context or user authorization scope. The vulnerable SQL pattern was UPDATE pnotes SET ... WHERE id = ? and SELECT body FROM pnotes WHERE id = ?, both of which were fixed by adding pid = ? to the WHERE clause. A concrete PoC is publicly documented in the GitHub Security Advisory: sending PUT /api/patient/1/note/777 with a JSON payload targeting a note belonging to a different patient results in unauthorized modification (GitHub Advisory, Patch Commit).

Successful exploitation allows an authenticated attacker to tamper with any patient's medical notes or messages across the entire OpenEMR deployment, regardless of which patients they are authorized to access. This poses a significant integrity and regulatory compliance risk — medical records could be falsified, diagnoses altered, or communications marked as resolved without clinical justification. There is no confidentiality or availability impact, but the integrity risk to protected health information (PHI) is high and could have serious patient safety and legal consequences (GitHub Advisory).

A proof-of-concept exploit is publicly available in the GitHub Security Advisory, consisting of a concrete HTTP request sequence that can be directly replicated against a vulnerable OpenEMR deployment. Exploitation requires authentication and notes write permission, but no elevated privileges beyond that. The EPSS score is approximately 0.026% (low probability of near-term exploitation), and there is no evidence of active in-the-wild exploitation or CISA KEV catalog listing as of the time of publication (GitHub Advisory).

1. Authenticate: Log in to the target OpenEMR instance as any user account that has been granted patient notes (write) permission.
2. Enumerate note IDs: Obtain a note/message ID belonging to a different patient through enumeration (e.g., incrementing IDs), a prior read operation, or information disclosed in another report or UI element. For example, identify that note ID 777 belongs to a patient other than patient 1.
3. Craft the malicious request: Send an HTTP PUT (or POST) request to the note update endpoint, specifying the target patient ID in the URL path but the victim patient's note ID as the resource identifier:

   PUT /api/patient/1/note/777 HTTP/1.1
   Host: target-openemr.com
   Authorization: Bearer <valid_token>
   Content-Type: application/json
   
   {"body": "Tampered content", "message_status": "Done"}

4. Verify unauthorized modification: Confirm that note ID 777 (belonging to a different patient) has been updated with the attacker-supplied content, demonstrating the server did not enforce patient ownership checks (GitHub Advisory).

• Network: HTTP PUT or POST requests to /api/patient/<pid>/note/<nid> where the note ID does not belong to the patient ID specified in the URL path; repeated requests with incrementing note IDs suggesting enumeration.
• Logs: OpenEMR API access logs showing a single authenticated user updating notes across multiple different patient IDs in a short time window; HTTP 200 responses to note update requests for patient IDs the user is not normally associated with.
• Database: Unexpected modifications to the pnotes table where the pid of updated records does not match the patient context of the authenticated user; audit trail entries showing note updates by users not assigned to those patients.
• Application: Notes or messages for patients marked as "Done" or with altered body content without corresponding clinical activity from authorized staff (GitHub Advisory).

The fix is available in commit 92a2ff9eaaa80674b3a934a6556e35e7aded5a41, which adds pid to the WHERE clause in MessageService::update() so that updates are restricted to notes belonging to the specified patient. Organizations should upgrade OpenEMR to a version incorporating this patch (post-8.0.0). As an interim measure, restrict notes write permissions to only the minimum necessary users, and audit recent changes to the pnotes table for unauthorized modifications. Review access logs for anomalous cross-patient note update activity (GitHub Advisory, Patch Commit).

The vulnerability was reported by security researchers simecek (reporter) and analysts pavelkohout396 and stanislavfortaisle, with remediation by OpenEMR developer kojiromike. A related advisory (GHSA-8gj5-r8vm-mghq) was filed separately for the same IDOR pattern in the web UI code paths (library/pnotes.inc.php), indicating a broader audit of the codebase. Coverage appeared on security aggregation sites including infinitsec.net and VulDB shortly after disclosure (GitHub Advisory).