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-weno/scripts/file_download.php has no ACL or CSRF check and ignores the result of validateAdminCredentials(). When the Weno module is enabled, the default GET path calls PharmacyService::removeWenoPharmacies() before attempting a refetch, allowing any authenticated user to truncate the weno_pharmacy table and allowing a cross-site request to trigger the same operation through a logged-in victim. A failed later download can leave the e-prescribing pharmacy directory empty and unavailable. This issue is fixed in version 8.3.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.4",
  "pubDate": "2026-11-05T20:17:38.510Z",
  "pubdate": "2026-11-05T20:17:38.510Z",
  "executiveSummary": "OpenEMR versions prior to 8.3.0 contain a critical authorization flaw within the oe-module-weno custom module. The vulnerability, located in interface/modules/custom_modules/oe-module-weno/scripts/file_download.php, stems from a lack of effective Access Control Lists (ACL) and Cross-Site Request Forgery (CSRF) protections. By design, the affected script invokes the PharmacyService::removeWenoPharmacies() function, which performs a destructive operation on the weno_pharmacy table.\nBecause the application fails to enforce the result of validateAdminCredentials(), any authenticated user—including those with low-level privileges—can execute this administrative function. Furthermore, the absence of CSRF tokens allows an attacker to orchestrate a cross-site request, forcing a logged-in victim (such as an administrator) to unknowingly trigger the table truncation. The primary impact is a Denial of Service (DoS) condition regarding the e-prescribing pharmacy directory, rendering the module effectively unavailable for clinical operations. Exploitation is trivial for authenticated users and does not require complex prerequisites, posing a significant risk to data availability in medical practice management environments.",
  "technicalDetails": "The vulnerability resides in the Weno module integration, specifically within the file_download.php script. The technical root cause is an improper authorization check wherein the script calls validateAdminCredentials() but fails to conditionally terminate execution if the validation returns false. This implementation flaw allows the script to proceed to sensitive operations regardless of the requester's identity or privilege level.\nWhen the script is accessed via a GET request, it triggers PharmacyService::removeWenoPharmacies(). This function executes a truncate operation on the weno_pharmacy database table. The application logic is flawed because it assumes the request is legitimate and authorized before attempting to fetch new pharmacy data. Because no CSRF protection mechanism is implemented for this endpoint, the operation is susceptible to request forgery. An attacker can host a malicious payload on an external site that targets the authenticated user's session in OpenEMR. When the victim visits the attacker-controlled page, the browser automatically includes the necessary session cookies in the forged request to the vulnerable endpoint.\nThe attack flow proceeds as follows: 1) An attacker identifies the accessible path interface/modules/custom_modules/oe-module-weno/scripts/file_download.php. 2) The attacker crafts a request or a malicious link designed to trigger this endpoint. 3) The application server receives the request and executes PharmacyService::removeWenoPharmacies(), clearing the persistent pharmacy directory data. 4) If the subsequent refetch process fails, the pharmacy directory remains empty, causing a systemic disruption to the e-prescribing workflow. The vulnerability exists because the code lacks a strictly enforced ACL, treating any authenticated session as having sufficient authorization to modify system-level database tables. This exposure affects OpenEMR versions prior to 8.3.0. The post-exploitation state results in a permanent loss of the cached pharmacy directory until a manual administrative intervention restores the data, effectively disabling the e-prescribing capabilities of the medical practice."
}