CVE-2026-25744: OpenEMR Auth Bypass Vulnerability

CVE-2026-25744 Overview

CVE-2026-25744 is an Insecure Direct Object Reference (IDOR) vulnerability in OpenEMR, a free and open source electronic health records (EHR) and medical practice management application. Prior to version 8.0.0.2, the encounter vitals API accepts an id parameter in the request body and treats it as an UPDATE operation without verifying that the vital record belongs to the current patient or encounter.

An authenticated user with encounters/notes permissions can exploit this flaw to overwrite any patient's vitals by supplying another patient's vital id, leading to medical record tampering. This poses significant risks in healthcare environments where data integrity is critical for patient safety and regulatory compliance.

Critical Impact
Authenticated attackers can tamper with any patient's vital signs records, potentially leading to misdiagnosis, incorrect treatment, or regulatory violations under HIPAA and other healthcare data protection regulations.

Affected Products

OpenEMR versions prior to 8.0.0.2
OpenEMR encounter vitals API (C_FormVitals.class.php)
OpenEMR EncounterRestController

Discovery Timeline

2026-03-19 - CVE-2026-25744 published to NVD
2026-03-19 - Last updated in NVD database

Technical Details for CVE-2026-25744

Vulnerability Analysis

This vulnerability is classified as CWE-639: Authorization Bypass Through User-Controlled Key. The core issue lies in the encounter vitals API's failure to validate ownership of vital records before performing update operations.

When a user submits a request to update vitals, the API accepts a user-supplied id parameter and directly uses it to fetch and update the corresponding vitals record. The vulnerable code in interface/forms/vitals/C_FormVitals.class.php retrieves the vitals record based solely on the provided ID without cross-referencing it against the current patient (pid) or encounter (eid) context.

This architectural flaw allows any authenticated user with encounters/notes permission to modify vitals data belonging to other patients by simply substituting the vital id in their request with that of a different patient's record.

Root Cause

The root cause is the absence of authorization checks in the vitals update workflow. The original code directly fetched vitals data using the user-supplied $_POST['id'] without verifying that the retrieved record's pid (patient ID) and eid (encounter ID) match the current session context stored in $GLOBALS['pid'] and $GLOBALS['encounter'].

Attack Vector

The vulnerability is exploitable over the network by any authenticated user with encounters/notes permissions. The attack requires:

Valid authentication to the OpenEMR system
Encounters/notes permission (commonly granted to clinical staff)
Knowledge or enumeration of another patient's vital record ID

An attacker can craft a malicious POST request to the vitals API endpoint, substituting the id parameter with a target patient's vital record ID to overwrite their medical data.

php

// Vulnerable code before patch in interface/forms/vitals/C_FormVitals.class.php
// grab our vitals data and then populate what is in the post
$vitalsService = new VitalsService();
$vitalsArray = $vitalsService->getVitalsForForm($_POST['id']) ?? [];
// No verification that the vital belongs to the current patient or encounter

Source: GitHub Commit Update

The security patch adds proper authorization verification:

php

// Patched code in interface/forms/vitals/C_FormVitals.class.php
// grab our vitals data and then populate what is in the post
$vitalsService = new VitalsService();
$vitalsArray = [];
if (!empty($_POST['id'])) {
    $vitalsArray = $vitalsService->getVitalsForForm($_POST['id']) ?? [];
    // Verify the vital belongs to this patient/encounter to prevent IDOR.
    // If not, treat as a new form (ignore the supplied id).
    if (
        !empty($vitalsArray)
        && ($vitalsArray['pid'] != $GLOBALS['pid'] || $vitalsArray['eid'] != $GLOBALS['encounter'])
    ) {
        $vitalsArray = [];
    }
}

Source: GitHub Commit Update

Detection Methods for CVE-2026-25744

Indicators of Compromise

Audit log entries showing vitals updates where the target patient ID differs from the session's patient context
Unusual patterns of vitals modifications by users accessing records outside their normal patient caseload
Database inconsistencies where vital record timestamps don't align with legitimate encounter workflows
Multiple vitals updates to different patients within short time windows from a single user session

Detection Strategies

Implement database-level auditing to track all UPDATE operations on the vitals table with full session context
Deploy application-level logging that captures the relationship between the authenticated user, session patient context, and modified record ownership
Configure SIEM rules to alert on vitals modifications where the modified record's pid doesn't match the active encounter's patient
Monitor for enumeration patterns where users access sequential or random vital record IDs

Monitoring Recommendations

Enable comprehensive audit logging for all patient data modification endpoints in OpenEMR
Implement real-time alerting for cross-patient data access attempts
Conduct periodic reviews of vitals modification logs to identify anomalous access patterns
Deploy integrity monitoring on critical patient record tables to detect unauthorized changes

How to Mitigate CVE-2026-25744

Immediate Actions Required

Upgrade OpenEMR to version 8.0.0.2 or later immediately
Audit vitals modification logs to identify any historical exploitation attempts
Review user permissions to ensure encounters/notes access is appropriately restricted
Enable detailed audit logging if not already active

Patch Information

OpenEMR has released version 8.0.0.2 which addresses this vulnerability. The fix implements proper authorization verification by comparing the retrieved vital record's pid and eid against the current session's patient and encounter context before allowing updates. If the ownership check fails, the system treats the request as a new form submission rather than an update.

For detailed patch information, see the GitHub Commit Update and GitHub Security Advisory GHSA-mv9m-j65p-g55f.

Workarounds

Restrict encounters/notes permissions to only essential clinical staff until the patch can be applied
Implement network-level access controls to limit API access to trusted segments
Deploy a Web Application Firewall (WAF) rule to inspect and validate vital form submissions
Enable database triggers to validate patient ownership on vitals table updates as a defense-in-depth measure

bash

# Example: Check current OpenEMR version and plan upgrade
# Navigate to OpenEMR installation directory
cd /var/www/html/openemr

# Check current version
cat version.php | grep -i version

# Backup before upgrade
mysqldump -u root -p openemr > openemr_backup_$(date +%Y%m%d).sql
tar -czvf openemr_files_backup_$(date +%Y%m%d).tar.gz /var/www/html/openemr

# Follow OpenEMR upgrade documentation for version 8.0.0.2