Description

OpenEMR is a free and open source electronic health records and medical practice management application. Prior to 8.3.0, custom/ajax_download.php, custom/download_qrda.php, custom/export_qrda_xml.php, and custom/qrda_download.php validate CSRF but do not enforce the patients/med ACL used by the canonical CQM report page. The endpoints also accept an unscoped report_id, allowing a low-privilege authenticated user to reach report generation and download logic for other reports. In a clinic with generated CQM reports, this can expose QRDA Category One and Category Three clinical documents for patients in a measure. This issue is fixed in version 8.3.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-11-05T20:17:39.450Z",
  "pubdate": "2026-11-05T20:17:39.450Z",
  "executiveSummary": "OpenEMR versions prior to 8.3.0 contain an Improper Access Control vulnerability affecting multiple file export and download scripts. The vulnerability exists because specific endpoints perform CSRF validation but fail to enforce the required 'patients/med' Access Control List (ACL) checks that are standard for clinical quality measure (CQM) reporting.\nThis flaw allows low-privilege authenticated users to bypass authorization mechanisms and access sensitive clinical data. By providing an unscoped 'report_id', an attacker can trigger the generation and download of QRDA Category One and Category Three clinical documents, which contain protected health information (PHI).\nThe risk implication is significant as it facilitates unauthorized data exfiltration of patient records. Successful exploitation requires an authenticated session within the application, but the attacker does not require elevated administrative or clinical privileges. This vulnerability exposes the organization to compliance risks and breaches of patient confidentiality.\nThe issue has been remediated in OpenEMR version 8.3.0 through the implementation of proper ACL enforcement across all affected report generation modules.",
  "technicalDetails": "The vulnerability is rooted in an inconsistency in authorization enforcement across the OpenEMR codebase. While the application utilizes a centralized ACL system—specifically the 'patients/med' ACL—to regulate access to sensitive clinical reporting features, several scripts located within the 'custom/' directory fail to invoke these checks during request handling.\nThe affected files include 'custom/ajax_download.php', 'custom/download_qrda.php', 'custom/export_qrda_xml.php', and 'custom/qrda_download.php'. Although these components correctly implement CSRF protection, they lack a server-side authorization check to verify whether the authenticated user possesses the 'patients/med' permission required to access specific clinical report generation logic.\nThe exploitation flow begins with a low-privilege authenticated user identifying a valid 'report_id' through enumeration or internal observation. The attacker submits a crafted HTTP request to one of the vulnerable endpoints, supplying the target 'report_id'. Because the server-side code does not validate the user's relationship to the requested record or verify the requisite ACL permissions, the application logic proceeds to execute the report generation sequence.\nThe server processes the 'report_id', retrieves the associated clinical data, and packages it into a QRDA (Quality Reporting Document Architecture) Category One or Category Three document. The final output is then returned to the attacker's browser session. This sequence enables unauthorized exfiltration of structured clinical health data.\nThe technical impact is an authorization bypass that elevates the privileges of any authenticated user to include sensitive medical report generation. Because the system trusts the provided 'report_id' implicitly without verifying ownership or authorization scope, the security boundary between unauthorized users and sensitive clinical reporting is rendered ineffective.\nThis vulnerability is restricted to versions prior to 8.3.0 and requires an active session, but does not rely on complex injection vectors; it is fundamentally a logic flaw where input validation does not extend to authorization scope enforcement."
}