CVE-2026-25745
Received Received - Intake
Insecure Direct Object Reference in OpenEMR Message Update

Publication date: 2026-03-18

Last updated on: 2026-03-20

Assigner: GitHub, Inc.

Description
OpenEMR is a free and open source electronic health records and medical practice management application. In versions up to and including 8.0.0, the message/note update endpoint (e.g. PUT or POST) updates by message/note ID only and does not verify that the message belongs to the current patient (or that the user is allowed to edit that patient’s notes). An authenticated user with notes permission can modify any patient’s messages by supplying another message ID. Commit 92a2ff9eaaa80674b3a934a6556e35e7aded5a41 contains a fix for the issue.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-03-18
Last Modified
2026-03-20
Generated
2026-05-07
AI Q&A
2026-03-18
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 (inc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-639 The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

[{'type': 'paragraph', 'content': "CVE-2026-25745 is an authorization bypass vulnerability in OpenEMR versions up to and including 8.0.0. It affects the message/note update endpoint, which updates patient notes by message ID without verifying that the note belongs to the current patient or that the user is authorized to edit that patient's notes."}, {'type': 'paragraph', 'content': "An authenticated user with permission to write notes can modify any patient's messages by supplying a different message ID. This happens because the system uses an SQL update statement that filters only by message ID and does not check patient ownership or user permissions."}, {'type': 'paragraph', 'content': 'The vulnerability allows unauthorized modification of patient communications or notes, risking data integrity. The expected secure behavior is to verify patient ownership and user permissions before allowing updates.'}] [1]


How can this vulnerability impact me? :

[{'type': 'paragraph', 'content': "This vulnerability allows an authenticated user with notes write permission to modify any patient's notes, not just their own or those they are authorized to edit."}, {'type': 'paragraph', 'content': 'The impact includes unauthorized modification of patient communications and notes, which compromises data integrity. This could lead to incorrect or misleading patient information being stored or displayed.'}, {'type': 'paragraph', 'content': 'Since the attack complexity is low and no user interaction is required beyond authentication, any deployment using the affected update endpoint is at risk if users have notes write permissions.'}] [1]


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 update patient notes using the message/note update REST API endpoint with a note ID that belongs to another patient. If the update succeeds without proper authorization checks, the system is vulnerable.'}, {'type': 'paragraph', 'content': 'A proof of concept involves the following steps:'}, {'type': 'list_item', 'content': 'Log in as a user with notes write permission.'}, {'type': 'list_item', 'content': 'Obtain a note ID from a different patient.'}, {'type': 'list_item', 'content': "Send a PUT request to the message/note update endpoint with the other patient's note ID and modified data."}, {'type': 'list_item', 'content': 'Observe if the note is updated despite belonging to a different patient.'}, {'type': 'paragraph', 'content': 'Example command using curl to test the vulnerability (replace placeholders accordingly):'}, {'type': 'paragraph', 'content': 'curl -X PUT https://<openemr-server>/api/notes/<other_patient_note_id> -H "Authorization: Bearer <token>" -H "Content-Type: application/json" -d \'{"body": "Modified note content"}\''}, {'type': 'paragraph', 'content': 'If the server updates the note without returning an HTTP 403 or 404 error, the vulnerability exists.'}] [1]


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation steps include:

  • Restrict notes write permissions to only trusted users to minimize the risk of unauthorized note modification.
  • Monitor and audit API usage for suspicious activity involving note updates with mismatched patient IDs.
  • Apply the fix from commit 92a2ff9eaaa80674b3a934a6556e35e7aded5a41 as soon as possible, which adds patient ID verification to the SQL queries in the message/note update endpoint.
  • If patching immediately is not possible, consider implementing additional access controls or input validation at the application or network level to prevent unauthorized note ID manipulation.

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