Description

OpenEMR is a free and open source electronic health records and medical practice management application. Prior to 8.4.0, controllers/C_Document.class.php write actions, including move_action_process(), do not verify the caller's access to the source document, current patient and category, or destination patient and category before Document::change_patient() performs the mutation. A low-privilege authenticated user can reassign an arbitrary document to a patient or category the user can access and then retrieve it through the normally protected read path. The reassignment occurs before a later list rendering check, so a final HTTP 403 response does not mean the unauthorized write was blocked. This issue is fixed in version 8.4.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.6",
  "pubDate": "2026-11-05T20:17:37.543Z",
  "pubdate": "2026-11-05T20:17:37.543Z",
  "executiveSummary": "OpenEMR versions prior to 8.4.0 contain a critical Broken Access Control vulnerability within the document management module. The flaw allows authenticated low-privilege users to perform unauthorized document reassignments, effectively bypassing patient data access controls.\nThe vulnerability resides in the controllers/C_Document.class.php file, specifically within the move_action_process() function. By failing to validate ownership or authorization for both source and destination patients, the application permits an attacker to move sensitive medical documents into accessible categories.\nThis impacts the confidentiality and integrity of protected health information (PHI) by allowing unauthorized retrieval of documents that are otherwise restricted. Exploitation requires an authenticated user account but no additional administrative privileges, making it a high-risk security flaw for healthcare environments where strict data segregation is required by regulatory standards.\nThe mutation is performed immediately upon the request; even if the final rendering process triggers a 403 error, the underlying database modification is already committed, ensuring the attacker successfully 'claims' the document before the defensive check occurs.",
  "technicalDetails": "The root cause of this vulnerability is an Insecure Direct Object Reference (IDOR) combined with insufficient server-side authorization checks in the document move workflow. Specifically, the function move_action_process() located in controllers/C_Document.class.php executes the Document::change_patient() method without verifying the caller's authorization context.\nThe application architecture relies on a trust-based model for document relocation, assuming that only authorized users will invoke the move action. However, the system fails to perform mandatory access control (MAC) or role-based access control (RBAC) validation against the source document ID, the source patient context, and the destination patient category. Because these checks are omitted, the application processes the mutation before validating the user's rights to the specific object being manipulated.\nThe attack flow proceeds as follows: First, an authenticated attacker identifies the unique identifiers (IDs) for a sensitive document they are not authorized to access. Second, the attacker crafts a malicious HTTP request targeting move_action_process() that identifies the target document and a destination patient/category that the attacker already has legitimate access to. Third, the server-side code executes Document::change_patient(), updating the database to associate the sensitive document with the attacker-controlled category. Finally, the attacker navigates to the authorized destination path to retrieve the document.\nA critical aspect of this flaw is the race-condition-like behavior regarding security checks. The document reassignment occurs server-side at the start of the process, persisting the change in the database. The subsequent list rendering check, which might result in an HTTP 403 response, happens post-mutation. Consequently, the user is denied access to the UI view of the results, but the document has already been reassigned in the backend database, granting the attacker permanent access via the standard read path after the move action is successfully triggered.\nThis vulnerability affects OpenEMR versions prior to 8.4.0. It requires a valid authentication session, but operates entirely within the application layer without requiring higher privileges, network-level access, or complex payload injection, posing a significant risk to the patient data privacy and HIPAA compliance of the affected installations."
}