CVE-2026-32121: 
OpenEMR vulnerability analysis and mitigation

CVE-2026-32121 is a stored DOM-based Cross-Site Scripting (XSS) vulnerability in OpenEMR, a free and open-source electronic health records and medical practice management application. The flaw exists in the portal signature modal component (portal/sign/assets/signer_api.js) where patient names are rendered unsanitized via jQuery's .html() method, allowing a low-privilege patient portal user to execute arbitrary JavaScript in a staff member's browser session. All OpenEMR versions prior to 8.0.0.1 are affected. The vulnerability was published on March 11, 2026, and patched in version 8.0.0.1. It carries a CVSS v3.1 base score of 7.7 (High) per the GitHub Security Advisory, or 5.4 (Medium) per NVD scoring (GitHub Advisory, Red Hat CVE).

The root cause is CWE-79 (Improper Neutralization of Input During Web Page Generation), specifically a DOM-based stored XSS sink. In portal/sign/assets/signer_api.js (line 279), the callModal function renders the patient's signer name using $('#openSignModal #labelName').html(" " + msgSignator + ": " + signerName + "") without HTML encoding. The signerName value originates from response.ptName or response.userName, fetched server-side from portal/sign/lib/show-signature.php, which queries patient_data.fname/lname and returns the value via js_escape() — defined as simply json_encode() with no HTML encoding. The patient self-registration flow ($_POST['fname']) bypasses staff review entirely, flowing unsanitized through verifyEmail() into the verify_email table and ultimately into patient_data via PatientController::Create(). No input validation exists (Patient::Validate() is an empty stub), and the Content-Security-Policy header on affected pages only restricts frame-ancestors, not inline scripts or event handlers. This vulnerability is distinct from a related server-side XSS (GHSA-4gh4-q39r-45wf) that uses raw PHP echo; both share the same root cause but differ in sink, component, and trigger (GitHub Advisory).

Successful exploitation allows a patient portal user to execute arbitrary JavaScript in the browser session of any clinical staff member who opens the signature modal for the attacker's patient record. This cross-boundary attack — from the patient portal context into the clinical staff interface — could enable session hijacking, exfiltration of sensitive protected health information (PHI) visible to the staff user, unauthorized modification of clinical records, or actions performed on behalf of the staff user. The scope change (patient portal to staff interface) significantly elevates the real-world impact, as staff accounts typically have broad access to patient data across the system (GitHub Advisory).

A proof-of-concept (PoC) exploit is publicly available in the GitHub Security Advisory, providing a concrete 6-step walkthrough demonstrating exploitation via a malicious patient first name (<img src=x onerror=alert(document.domain)>). Exploitation requires two preconditions: patient self-registration must be enabled in OpenEMR, and a staff member must interact with the attacker's patient record by clicking the signature modal. There is no evidence of in-the-wild exploitation at this time. The EPSS score is approximately 0.0017 (0.17%), indicating low probability of near-term automated exploitation. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog (GitHub Advisory, Red Hat CVE).

1. Enable self-registration: Confirm that patient self-registration is enabled in the target OpenEMR instance (Administration > Globals > Portal > Enable Patient Self Registration).
2. Register malicious patient: Navigate to the patient portal registration page and register a new patient with the first name set to a malicious HTML payload, e.g., <img src=x onerror=alert(document.domain)> (or a more sophisticated payload for session theft or data exfiltration).
3. Complete registration: Finish the email verification and registration flow so the malicious name is stored in patient_data in the database, bypassing staff review via the self-registration path.
4. Wait for staff interaction: The payload is now stored and will trigger when any staff member opens the attacker's patient record and navigates to an LBF (Layout Based Form) or document containing a signature field.
5. Trigger the vulnerable code path: When the staff member clicks the signature image placeholder (pen icon), signer_api.js makes a POST request to portal/sign/lib/show-signature.php with mode: fetch_info, which returns the unsanitized patient name.
6. XSS execution: The callModal function renders the attacker-controlled name via jQuery .html(), causing the browser to parse the injected HTML and execute the embedded JavaScript in the staff member's browser session, enabling session token theft, PHI exfiltration, or record modification (GitHub Advisory).

• Network: Unusual POST requests to portal/sign/lib/show-signature.php with mode=fetch_info from staff-side sessions; unexpected outbound connections from staff browsers to attacker-controlled domains following signature modal interactions.
• Logs: OpenEMR access logs showing patient self-registration events with anomalous characters (<, >, ", onerror, script) in the fname or lname fields; server-side logs recording the registration of patients with HTML markup in name fields.
• Database: Records in patient_data or verify_email tables where fname or lname fields contain HTML tags or JavaScript event handlers (e.g., <img, <script, onerror=, onload=).
• Browser/Client-Side: Unexpected JavaScript alerts, redirects, or network requests originating from the OpenEMR staff interface after opening a patient signature modal; browser developer tools showing DOM manipulation via .html() with unsanitized content (GitHub Advisory).

The vendor has released a patch in OpenEMR version 8.0.0.1, which is the recommended remediation. Administrators should upgrade immediately, particularly if patient self-registration is enabled. As interim mitigations, disabling patient self-registration (Administration > Globals > Portal > Enable Patient Self Registration) removes the primary attack vector. Additionally, implementing proper HTML entity encoding before passing patient name data to jQuery .html() (or replacing .html() with .text() where HTML rendering is not required), adding server-side input validation to reject HTML markup in name fields, and deploying a robust Content Security Policy (CSP) that restricts inline scripts can reduce exposure (GitHub Advisory).

The vulnerability was reported by researcher pavelkohout396 and analyzed by simecek, with the advisory published by kojiromike on GitHub. Social media coverage was noted on Mastodon (via @thehackerwire) and Bluesky shortly after disclosure. A security blog post specifically covering this vulnerability was published at infinitsec.net. Aisle.com published a broader blog post highlighting 38 critical security vulnerabilities discovered in healthcare software used by 100,000+ providers, which included this finding, drawing attention to the systemic security risks in OpenEMR (GitHub Advisory).