CVE-2026-25744
Insecure Direct Object Reference in OpenEMR Encounter Vitals API
Publication date: 2026-03-19
Last updated on: 2026-03-20
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.2 (exc) |
Helpful Resources
Exploitability
| 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
How can this vulnerability impact me? :
[{'type': 'paragraph', 'content': "This vulnerability allows an authenticated user with certain permissions to modify any patient's vital signs data, such as blood pressure, weight, and height, without authorization."}, {'type': 'paragraph', 'content': 'The impact includes unauthorized tampering with clinical data, which can lead to incorrect medical records and potentially harmful treatment decisions based on falsified or altered patient vitals.'}, {'type': 'paragraph', 'content': 'Any deployment of OpenEMR where users have encounters or vitals access is at risk, potentially compromising the integrity of patient health information.'}] [2]
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
Can you explain this vulnerability to me?
[{'type': 'paragraph', 'content': "CVE-2026-25744 is an authorization bypass vulnerability in the OpenEMR electronic health records system. The vulnerability exists in the encounter vitals API, which accepts an 'id' parameter in the request body and treats it as an update operation without verifying if the vital record belongs to the current patient or encounter."}, {'type': 'paragraph', 'content': "An authenticated user with encounters/notes or vitals permissions can exploit this by supplying another patient's vital record ID, allowing them to overwrite that patient's vitals data. This leads to unauthorized modification of medical records, also known as medical record tampering."}, {'type': 'paragraph', 'content': 'The issue was fixed in OpenEMR version 8.0.0.2 by adding ownership verification checks that ensure the vital record being updated belongs to the current patient and encounter before allowing any modifications.'}] [1, 2]
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 monitoring API requests to the OpenEMR encounter vitals endpoint for suspicious activity where a user supplies a vital record ID (id) that does not belong to the current patient or encounter.'}, {'type': 'paragraph', 'content': "Specifically, detection involves identifying POST or PUT requests to endpoints like `/api/encounter/{pid}/{eid}/vital` where the request body contains an 'id' parameter referencing a vital record belonging to a different patient."}, {'type': 'paragraph', 'content': 'Commands to detect such activity could include inspecting web server logs or API gateway logs for requests with mismatched patient IDs and vital record IDs.'}, {'type': 'list_item', 'content': "Use grep or similar tools to search logs for POST or PUT requests containing 'id' parameters in the vitals API endpoint."}, {'type': 'list_item', 'content': 'Example command: `grep -i \'POST /api/encounter/\' /var/log/openemr_access.log | grep \'"id":\'`'}, {'type': 'list_item', 'content': "Analyze the extracted requests to verify if the 'id' in the request body corresponds to the patient and encounter in the URL path."}, {'type': 'paragraph', 'content': 'Additionally, monitoring for unexpected 403 Forbidden or 404 Not Found responses after the patch can help identify attempts to exploit this vulnerability.'}] [2]
What immediate steps should I take to mitigate this vulnerability?
[{'type': 'paragraph', 'content': 'The immediate mitigation step is to upgrade OpenEMR to version 8.0.0.2 or later, where the vulnerability has been fixed by enforcing ownership verification on vital record updates.'}, {'type': 'paragraph', 'content': 'If upgrading immediately is not possible, restrict access to the encounter vitals API endpoints to only trusted and authorized users with the minimum necessary permissions.'}, {'type': 'paragraph', 'content': 'Implement monitoring and alerting on API requests that attempt to update vitals with mismatched patient or encounter IDs.'}, {'type': 'paragraph', 'content': 'Review and audit user permissions to ensure only users with legitimate encounters/notes or vitals permissions can access these endpoints.'}, {'type': 'paragraph', 'content': "Consider applying custom access control rules or web application firewall (WAF) rules to block requests that include an 'id' parameter in the vitals update payload that does not match the authenticated patient's records."}] [1, 2]