CVE-2026-25164: OpenEMR Auth Bypass Vulnerability

CVE-2026-25164 Overview

CVE-2026-25164 is an authorization bypass vulnerability in OpenEMR, a free and open source electronic health records (EHR) and medical practice management application. The vulnerability exists in the REST API route table where critical authorization checks are missing for document and insurance routes, allowing any authenticated API client to access or modify protected health information (PHI) regardless of their assigned access control list (ACL) permissions.

Critical Impact

Any valid API bearer token can access or modify every patient's documents and insurance data, effectively exposing all document and insurance PHI to any authenticated API client—a severe HIPAA compliance concern for healthcare organizations.

Affected Products

• OpenEMR versions prior to 8.0.0
• OpenEMR REST API document routes (/api/patient/:pid/document)
• OpenEMR REST API insurance routes

Discovery Timeline

• 2026-02-25 - CVE-2026-25164 published to NVD
• 2026-02-26 - Last updated in NVD database

Technical Details for CVE-2026-25164

Vulnerability Analysis

This vulnerability represents a classic Broken Access Control (CWE-862: Missing Authorization) issue within OpenEMR's REST API implementation. The affected code resides in apis/routes/_rest_routes_standard.inc.php, which defines the routing table for the application's REST API endpoints.

The core issue is that document and insurance-related routes fail to invoke RestConfig::request_authorization_check(), a critical function responsible for validating that the requesting user possesses the appropriate ACL permissions before proceeding with the operation. Other patient routes in the same file properly call this function with appropriate ACL parameters (e.g., encounters, patients/med), creating an inconsistency that exposes sensitive medical data.

Root Cause

The root cause is inconsistent security implementation across REST API routes. While the OpenEMR development team implemented proper authorization checks for most patient-related endpoints, the document and insurance routes were inadvertently left unprotected. This oversight means the API only validates that a bearer token is valid (authentication), but does not verify whether that token's associated user has permission to access the specific resource (authorization).

Attack Vector

An attacker who possesses any valid API bearer token—even one with minimal ACL permissions—can exploit this vulnerability to access or modify any patient's documents and insurance information across the entire OpenEMR installation. The attack requires network access and a valid authenticated session, but no specific privilege level within the application.

The following patch demonstrates the security fix applied in version 8.0.0:

      *  )
      */
     "POST /api/patient/:pid/document" => function ($pid, HttpRestRequest $request) {
+        RestConfig::request_authorization_check($request, "patients", "docs", ['write','addonly']);
         $controller = new DocumentRestController();
         $controller->setSession($request->getSession());
         $return = $controller->postWithPath($pid, $_GET['path'], $_FILES['document']);

Source: GitHub Commit Update

The patch adds the missing RestConfig::request_authorization_check() call with appropriate ACL parameters ("patients", "docs", ['write','addonly']), ensuring that only users with proper document write permissions can access the endpoint.

Detection Methods for CVE-2026-25164

Indicators of Compromise

• Unusual API access patterns to /api/patient/*/document endpoints from users without document ACL permissions
• API requests accessing multiple patients' documents in rapid succession from a single session
• Unexpected modifications to patient insurance records through the REST API
• Access log entries showing document or insurance API calls from low-privilege API tokens

Detection Strategies

• Implement API request logging and monitor for anomalous access to document and insurance endpoints
• Review OpenEMR audit logs for unauthorized PHI access patterns
• Deploy web application firewall (WAF) rules to detect unusual REST API request volumes
• Correlate API access logs with user ACL configurations to identify potential exploitation

Monitoring Recommendations

• Enable detailed API access logging in OpenEMR configuration
• Implement real-time alerting for bulk document access operations
• Monitor for API tokens accessing resources outside their normal scope
• Conduct periodic access control audits comparing user permissions against actual API activity

How to Mitigate CVE-2026-25164

Immediate Actions Required

• Upgrade OpenEMR to version 8.0.0 or later immediately
• Audit API access logs for any unauthorized access to document or insurance endpoints
• Review and rotate all API bearer tokens as a precautionary measure
• Conduct a breach assessment to determine if PHI was accessed prior to patching

Patch Information

OpenEMR version 8.0.0 contains the official fix for this vulnerability. The patch adds proper authorization checks to the document and insurance REST API routes by implementing RestConfig::request_authorization_check() with appropriate ACL parameters. Organizations should upgrade to version 8.0.0 or apply the security commit referenced in the GitHub Security Advisory.

Workarounds

• Disable the REST API entirely if not required for operations until patching is complete
• Implement network-level restrictions to limit API access to trusted IP ranges only
• Deploy a reverse proxy or WAF to block requests to vulnerable endpoints (/api/patient/*/document, /api/patient/*/insurance)
• Manually apply the authorization check patch from commit c5e1c44 if immediate upgrade is not feasible

# Configuration example - Restrict API access via Apache .htaccess
# Place in OpenEMR web root to block vulnerable endpoints until patch is applied
<LocationMatch "^/apis/.*/api/patient/.*/document">
    Require ip 10.0.0.0/8 192.168.0.0/16
</LocationMatch>

<LocationMatch "^/apis/.*/api/patient/.*/insurance">
    Require ip 10.0.0.0/8 192.168.0.0/16
</LocationMatch>