CVE-2026-32119: 
OpenEMR vulnerability analysis and mitigation

CVE-2026-32119 is a DOM-based stored Cross-Site Scripting (XSS) vulnerability in OpenEMR's jQuery SearchHighlight plugin (library/js/SearchHighlight.js). It affects all OpenEMR versions prior to 8.0.0.2 and allows an authenticated user with encounter form write access to inject arbitrary JavaScript that executes in another clinician's browser session when they use the single-word search feature on the Custom Report page. The vulnerability was published on March 19, 2026, and patched in version 8.0.0.2. It carries a CVSS v3.1 base score of 4.4 (Medium) (GitHub Advisory).

The root cause is CWE-79 (Improper Neutralization of Input During Web Page Generation). The vulnerable hiliteTree() function in library/js/SearchHighlight.js (lines 180–196) reads text from DOM text nodes — where the browser has already decoded server-side HTML entity encoding (e.g., < becomes <) — concatenates these decoded strings directly into a raw HTML string, and passes the result to jQuery's $() constructor, which parses it as live HTML. This effectively bypasses server-side escaping: the server correctly stores and renders the payload as HTML entities, but the plugin reconstructs it into executable markup. The attack requires the victim to perform a single-word search on the Custom Report page that matches a word in the same text node as the stored payload; multi-word searches use a different, safe code path (GitHub Advisory, Patch Commit).

Successful exploitation allows the injected script to execute in the victim clinician's authenticated browser session, potentially exposing session tokens, CSRF tokens, and enabling unauthorized actions on behalf of the victim. Given that OpenEMR handles sensitive electronic health records (EHR) for medical practices, this could lead to unauthorized access to or modification of patient health data. The scope is limited to encounter form sections rendered within search_div_* containers on the Custom Report page; demographics, patient notes, history, insurance, and other top-level sections are not affected (GitHub Advisory).

A proof-of-concept (PoC) with step-by-step reproduction instructions is publicly available in the GitHub Security Advisory, including specific payloads and trigger conditions (GitHub Advisory). There is no evidence of in-the-wild exploitation at this time. The EPSS score is approximately 0.029% (0.000290), indicating a low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires authentication and low privileges (encounter form write access), plus user interaction from the victim, which limits the attack surface.

1. Gain access: Log into OpenEMR as any authenticated user with permission to create or edit encounter forms.
2. Inject payload: Open a patient encounter and add or edit a form with a free-text field (e.g., SOAP notes). Enter a value containing an XSS payload alongside a common word, such as: routine checkup <img src=x onerror=alert(document.domain)>. Save the form.
3. Verify storage: Confirm the payload is stored in the database and rendered as properly escaped HTML entities on the Custom Report page (angle brackets appear as literal text, not markup).
4. Trigger execution: As the attacker or by social engineering a victim clinician, navigate to the patient's Custom Report page (interface/patient_file/report/custom_report.php), select the encounter containing the form with the payload, and in the "Find" box type a single word that appears in the same text node as the payload (e.g., routine), then click Search.
5. XSS fires: The SearchHighlight plugin reads the browser-decoded text node, reconstructs it as raw HTML, and passes it to jQuery's $() constructor. The <img> element is created as a live DOM node, firing the onerror handler and executing arbitrary JavaScript in the victim's authenticated session (GitHub Advisory).

• Logs: OpenEMR application logs showing access to interface/patient_file/report/custom_report.php followed by single-word search queries from clinician accounts; audit logs showing encounter form edits by users who do not typically modify clinical notes.
• File System: No file-system artifacts expected for this client-side XSS; however, if the injected script exfiltrates data, review web server access logs for unexpected outbound requests or data submissions to external domains.
• Network: Unusual outbound HTTP/HTTPS requests originating from clinician browsers to external or unexpected domains immediately after accessing the Custom Report page; potential exfiltration of session cookies or tokens to attacker-controlled endpoints.
• Application Behavior: Unexpected actions performed under a clinician's session (e.g., unauthorized record access, form submissions, or configuration changes) that do not align with the user's normal activity pattern (GitHub Advisory).

Upgrade OpenEMR to version 8.0.0.2 or later, which adds an escapeHtml() helper function to the SearchHighlight plugin that properly escapes HTML special characters before concatenating text into the highlight span HTML string (Patch Commit). As interim mitigations: restrict encounter form write access to only trusted and necessary users; implement Content Security Policy (CSP) headers to reduce XSS impact; and monitor access logs for users with encounter form write permissions. There is no configuration-only workaround that fully eliminates the vulnerability without patching.

The vulnerability was discovered and reported by security researchers pavelkohout396 (reporter), simecek, and stanislavfortaisle (analysts) from Aisle, who disclosed it as part of a broader research effort identifying 38 security vulnerabilities in OpenEMR, a healthcare application used by over 100,000 providers (Aisle Blog). The advisory was published responsibly through GitHub's coordinated disclosure process, with a patch released simultaneously.