CVE-2026-25164: 
OpenEMR vulnerability analysis and mitigation

CVE-2026-25164 is a missing authorization vulnerability in OpenEMR, a widely used open-source electronic health records (EHR) and medical practice management application. Prior to version 8.0.0, the REST API route table in apis/routes/_rest_routes_standard.inc.php omits calls to RestConfig::request_authorization_check() for document and insurance endpoints, allowing any valid API bearer token to access or modify all patients' documents and insurance data regardless of the token's assigned ACLs. The vulnerability was disclosed on February 25, 2026, and affects all OpenEMR versions before 8.0.0. It carries a CVSS v3.1 base score of 8.1 (High) (GitHub Advisory, Feedly).

The root cause is CWE-862 (Missing Authorization): the document routes (POST /api/patient/:pid/document, GET /api/patient/:pid/document, GET /api/patient/:pid/document/:did) and insurance routes (GET /api/patient/:puuid/insurance, GET /api/patient/:puuid/insurance/$swap-insurance, GET /api/patient/:puuid/insurance/:uuid) invoke their respective controllers directly without first calling RestConfig::request_authorization_check(), unlike other patient routes such as encounters and medications that correctly enforce ACL checks. An attacker with any valid OAuth2 or API bearer token — even one scoped to minimal permissions like patients/demo read — can supply an arbitrary patient ID or UUID in the URL path to retrieve or upload documents and read or modify insurance assignments for any patient. The fix, applied in commit c5e1c44, adds the appropriate request_authorization_check() calls with the correct ACL parameters (patients/docs for documents, patients/demo for insurance) to each affected route (GitHub Advisory, GitHub Commit).

Successful exploitation exposes all patients' Protected Health Information (PHI) — including medical documents and insurance records — to any authenticated API client, regardless of their assigned permissions. An attacker can read documents and insurance data in bulk across all patients, upload documents to any patient's record, and swap insurance assignments, compromising both confidentiality and integrity of sensitive medical and financial data. All OpenEMR deployments with the REST API enabled and any issued API bearer tokens are affected; the vulnerability does not impact availability but poses significant regulatory risk (e.g., HIPAA) due to mass PHI exposure (GitHub Advisory).

A proof-of-concept exploit is publicly documented in the GitHub Security Advisory, detailing exact HTTP requests needed to exploit each vulnerable endpoint. There is no confirmed evidence of in-the-wild exploitation at this time, and no threat actor attribution has been reported. The EPSS score is approximately 0.028% (low probability of near-term exploitation), and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires only a valid API bearer token (low privilege), no user interaction, and is achievable over the network with low complexity (GitHub Advisory, Feedly).

1. Reconnaissance: Identify internet-facing OpenEMR instances running versions prior to 8.0.0 with the REST API enabled, using tools like Shodan or Censys searching for OpenEMR login pages or API endpoints.
2. Obtain a bearer token: Authenticate to the OpenEMR REST API using any valid API credentials — even a low-privilege account (e.g., one with only patients/demo read ACL) — via the OAuth2 flow to obtain a bearer token.
3. List documents for an arbitrary patient: Send a GET request to enumerate documents for any patient ID without ACL enforcement:

   GET /apis/api/patient/1/document?path=/ HTTP/1.1
   Host: target-openemr.com
   Authorization: Bearer <token>

4. Download a specific document: Use document IDs from the listing response to download files belonging to any patient:

   GET /apis/api/patient/5/document/123 HTTP/1.1
   Host: target-openemr.com
   Authorization: Bearer <token>

5. Retrieve insurance data: Access full insurance records for any patient by UUID:

   GET /apis/api/patient/<puuid>/insurance HTTP/1.1
   Host: target-openemr.com
   Authorization: Bearer <token>

6. Modify insurance assignments: Swap insurance for any patient using the unprotected swap endpoint:

   GET /apis/api/patient/<puuid>/insurance/$swap-insurance?type=primary&uuid=<uuid> HTTP/1.1
   Host: target-openemr.com
   Authorization: Bearer <token>

7. Exfiltrate PHI at scale: Iterate over patient IDs or UUIDs to bulk-collect documents and insurance data across all patients in the system (GitHub Advisory).

• Network: Unusual volume of API requests to /apis/api/patient/*/document or /apis/api/patient/*/insurance endpoints from a single bearer token or IP address; requests accessing document/insurance endpoints for patient IDs that do not correspond to the authenticated user's expected scope.
• Logs: OpenEMR API access logs showing repeated GET/POST requests to document and insurance routes with varying patient IDs or UUIDs from the same token; successful 200 responses to these endpoints from tokens with minimal ACL assignments.
• Application Behavior: API tokens with restricted ACLs (e.g., patients/demo only) successfully returning document metadata or insurance records; document upload (POST) activity from tokens not expected to have write access to patient documents.
• File System: Unexpected new documents appearing in patient document categories that were not uploaded through normal clinical workflows (GitHub Advisory).

Upgrade OpenEMR to version 8.0.0 or later, which adds the required RestConfig::request_authorization_check() calls to all affected document and insurance REST API routes (GitHub Commit). Organizations unable to upgrade immediately should consider disabling the REST API entirely if it is not operationally required, or restricting network access to the API endpoints via firewall rules or reverse proxy controls. Additionally, audit existing API bearer tokens and revoke any that are not strictly necessary, and monitor API access logs for anomalous access patterns to document and insurance endpoints (GitHub Advisory).

The vulnerability was reported by researchers simecek (reporter) and pavelkohout396 (analyst) and published by OpenEMR maintainer bradymiller on February 25, 2026. Aisle, a security research firm, highlighted this vulnerability as part of a broader disclosure of 38 critical security vulnerabilities found in healthcare software used by over 100,000 providers (Aisle Blog). The vulnerability was tracked by Red Hat's security advisory system and aggregated by multiple vulnerability intelligence platforms shortly after disclosure (Red Hat CVE).