Description

OpenEMR is a free and open source electronic health records and medical practice management application. Prior to 8.3.0, interface/modules/custom_modules/oe-module-dorn/public/compendium_install.php checks authentication and CSRF but does not require the admin/users ACL enforced by sibling DORN administration scripts. When the DORN module is enabled, a low-privilege authenticated user can supply a labGuid that causes LabCompendiumInstall::uninstall() to delete detail and result procedure types and deactivate order types before the reinstall step. The action can corrupt lab-ordering configuration and require an administrator to restore the compendium. This issue is fixed in version 8.3.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.1",
  "pubDate": "2026-11-05T20:17:38.670Z",
  "pubdate": "2026-11-05T20:17:38.670Z",
  "executiveSummary": "This vulnerability is an Improper Access Control flaw within the OpenEMR DORN module, specifically affecting the compendium installation component.\nThe vulnerability allows a low-privilege authenticated user to trigger unauthorized administrative operations by bypassing necessary Access Control List (ACL) checks that are enforced in other administrative scripts within the module.\nBy submitting a specially crafted labGuid, an attacker can invoke the LabCompendiumInstall::uninstall() function, leading to the destructive removal of critical lab-ordering configuration data.\nThe primary impact is a loss of availability for lab procedures and order types, causing system-wide configuration corruption that requires manual administrative intervention to restore.\nThe vulnerability affects OpenEMR versions prior to 8.3.0 when the DORN module is active.\nExploitation requires the attacker to be authenticated within the application but does not require administrative privileges, representing a significant escalation of risk regarding system integrity.\nThere are no requirements for network access beyond standard application access, as the vulnerability resides within the internal interface modules.",
  "technicalDetails": "The root cause of this vulnerability is an inconsistent implementation of authorization logic within the 'interface/modules/custom_modules/oe-module-dorn/public/compendium_install.php' script. While the script performs rudimentary authentication and CSRF checks, it fails to enforce the mandatory admin/user ACLs required for executing administrative functions within the DORN module.\nThe vulnerable component is the LabCompendiumInstall class, specifically the 'uninstall()' method, which lacks proper privilege validation. The application design assumes that only administrators will access the installation scripts; however, the lack of programmatic enforcement of these roles at the entry point allows any authenticated user to interact with the underlying logic.\nThe exploitation flow is as follows: 1) An authenticated attacker identifies the target endpoint at 'interface/modules/custom_modules/oe-module-dorn/public/compendium_install.php'. 2) The attacker crafts an HTTP request containing a 'labGuid' parameter. 3) The script processes the request without validating the user's role against the required administrative ACLs. 4) The application passes the attacker-supplied 'labGuid' to the 'LabCompendiumInstall::uninstall()' method.\nOnce the 'uninstall()' method is executed, the application performs a series of high-impact database operations. It systematically deletes detail and result procedure types associated with the provided GUID and forces the deactivation of order types. This process is intended to be a precursor to a reinstall step, but because an unauthorized user can trigger the initial 'uninstall' phase, the system is left in a state of partial or complete data loss.\nThe post-exploitation impact is severe for medical practice operations, as the deletion of procedure types corrupts the lab-ordering configuration. This disrupts the clinic's ability to process lab results or generate new orders, requiring administrative restoration from backups or manual reconfiguration of the compendium. This vulnerability demonstrates a failure in the 'secure by default' principle where administrative administrative controllers were exposed to lower-privileged application users due to inadequate function-level access control."
}