CVE-2025-43860 is a high-severity stored cross-site scripting (XSS) vulnerability affecting OpenEMR, an open-source electronic health records (EHR) and medical practice management system widely used in healthcare environments. This vulnerability exists in versions prior to 7.0.3.4 and allows any authenticated user with patient creation and editing privileges to inject arbitrary JavaScript code into the system. The injection points include multiple input fields within the Additional Addresses section of the Contact tab in Patient Demographics: specifically, the Text Box fields for Address, Address Line 2, Postal Code, and City, as well as the Drop Down menu options for Address Use, State, and Country. The malicious script can execute in two scenarios: dynamically during form input and when the form data is subsequently loaded for editing. This means that the injected payload can trigger immediately as the user interacts with the form or later when the data is revisited, increasing the risk of persistent exploitation. The vulnerability arises from improper neutralization of input during web page generation, classified under CWE-79. The CVSS v3.1 score is 7.6, reflecting a high severity due to network attack vector, low attack complexity, requiring privileges but with user interaction, and causing high confidentiality impact with limited integrity impact and no availability impact. The vulnerability has not been reported exploited in the wild yet. The vendor has addressed the issue in version 7.0.3.4 by patching the input validation and sanitization mechanisms. Given the nature of OpenEMR as a critical healthcare application managing sensitive patient data, exploitation of this XSS flaw could lead to session hijacking, theft of sensitive health information, unauthorized actions on behalf of users, and potential pivoting within the healthcare network.

For European organizations, particularly healthcare providers using OpenEMR, this vulnerability poses significant risks. Exploitation could lead to unauthorized disclosure of sensitive patient health information, violating GDPR and other data protection regulations, resulting in legal and financial penalties. The ability to execute arbitrary JavaScript in the context of authenticated users could enable attackers to hijack user sessions, manipulate patient records, or implant further malware, undermining the integrity of medical data and trust in healthcare IT systems. Given the critical nature of healthcare services, any disruption or data breach could have severe consequences for patient safety and organizational reputation. Additionally, the persistent nature of stored XSS means that multiple users could be affected over time, amplifying the impact. The requirement for authenticated access limits exploitation to insiders or compromised accounts, but this is a realistic threat vector in healthcare environments where multiple staff members have editing privileges. The dynamic execution during form input and on data reload increases the attack surface and potential for unnoticed exploitation.

European healthcare organizations using OpenEMR should urgently upgrade to version 7.0.3.4 or later to apply the official patch addressing this vulnerability. Until the upgrade is complete, implement strict access controls to limit patient creation and editing privileges only to trusted personnel, minimizing the number of users who can inject malicious payloads. Conduct thorough audits of user accounts and monitor for unusual activity indicative of exploitation attempts. Employ web application firewalls (WAFs) with custom rules to detect and block common XSS payload patterns targeting the vulnerable fields. Enhance input validation and output encoding at the application layer if possible, especially for the affected fields in patient demographics. Train staff on phishing and social engineering risks to reduce the chance of credential compromise. Regularly review and sanitize existing patient data entries to detect and remove any malicious scripts that may have been injected prior to patching. Finally, implement robust logging and alerting mechanisms to detect suspicious behavior related to patient record modifications.