CVE-2026-33911: OpenEMR Cross-Site Scripting Vulnerability

CVE-2026-33911 Overview

CVE-2026-33911 is a Reflected Cross-Site Scripting (XSS) vulnerability in OpenEMR, a widely-used free and open source electronic health records (EHR) and medical practice management application. The vulnerability exists in versions prior to 8.0.0.3 where the POST parameter title is reflected back in a JSON response built with json_encode(). Due to the response being served with a text/html Content-Type header instead of application/json, browsers interpret injected HTML and script tags rather than treating the output as JSON data.

An authenticated attacker can craft a malicious request that executes arbitrary JavaScript in the context of a victim's browser session, potentially leading to session hijacking, data theft, or unauthorized actions within the healthcare application.

Critical Impact

This XSS vulnerability in a healthcare application could allow attackers to steal patient health information, hijack administrator sessions, or perform unauthorized medical record modifications.

Affected Products

• OpenEMR versions prior to 8.0.0.3
• open-emr openemr

Discovery Timeline

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

Technical Details for CVE-2026-33911

Vulnerability Analysis

This vulnerability (CWE-79) is a Reflected Cross-Site Scripting flaw that occurs due to improper handling of Content-Type headers in JSON responses. When a user-controlled title parameter is processed by the application, it passes through PHP's json_encode() function and is reflected in the HTTP response. While json_encode() typically provides some protection by escaping certain characters, the critical flaw lies in the server responding with Content-Type: text/html instead of the appropriate application/json.

This Content-Type mismatch causes web browsers to parse the response as HTML rather than JSON data. As a result, injected HTML elements and JavaScript code within the title parameter are executed by the browser in the security context of the OpenEMR application domain.

Root Cause

The root cause of this vulnerability is the incorrect Content-Type header being set for JSON responses. When server-side code returns JSON data but specifies text/html as the Content-Type, browsers follow the Content-Type directive and render the content as HTML. This allows malicious payloads embedded in JSON field values to be interpreted as executable HTML/JavaScript.

The proper fix requires ensuring that all JSON responses are served with Content-Type: application/json, which instructs browsers to treat the content strictly as JSON data and prevents script execution.

Attack Vector

The attack is network-based and requires the attacker to have valid authentication credentials for the OpenEMR system. The attacker must then craft a malicious URL or form submission containing XSS payloads in the title POST parameter and convince an authenticated victim (such as an administrator or healthcare provider) to trigger the malicious request.

Upon successful exploitation, the injected JavaScript executes in the victim's authenticated session, potentially allowing the attacker to steal session cookies, access sensitive patient health information, modify medical records, or perform administrative actions on behalf of the victim.

Since no verified code examples are available, the vulnerability mechanism can be understood as follows: when a POST request includes script tags or event handlers in the title parameter, the server reflects this input in a response that the browser treats as HTML, causing the malicious code to execute. For detailed technical information, refer to the GitHub Security Advisory.

Detection Methods for CVE-2026-33911

Indicators of Compromise

• Unusual HTTP POST requests containing HTML tags or JavaScript code in the title parameter
• Web server access logs showing encoded script payloads (<script>, onerror=, onload=) in request parameters
• Reports of unexpected JavaScript alerts or browser behavior from OpenEMR users
• Authentication session anomalies or unauthorized actions traced back to XSS exploitation

Detection Strategies

• Implement Web Application Firewall (WAF) rules to detect and block XSS payloads in POST parameters targeting OpenEMR endpoints
• Monitor HTTP responses for text/html Content-Type headers on endpoints that should return JSON data
• Deploy browser-based XSS protection monitoring through Content Security Policy (CSP) violation reports
• Review application logs for suspicious patterns in user-supplied input fields

Monitoring Recommendations

• Enable detailed logging for all POST requests to OpenEMR endpoints handling user input
• Configure alerts for Content-Type header mismatches between expected JSON responses and actual text/html responses
• Implement real-time monitoring for XSS attack signatures in web traffic
• Establish baseline behavior patterns for the title parameter and alert on deviations

How to Mitigate CVE-2026-33911

Immediate Actions Required

• Upgrade OpenEMR to version 8.0.0.3 or later immediately
• Audit web server and application configurations to ensure JSON endpoints return Content-Type: application/json
• Implement Content Security Policy (CSP) headers to provide defense-in-depth against XSS attacks
• Review user session logs for signs of potential exploitation prior to patching

Patch Information

OpenEMR has released version 8.0.0.3 which contains the fix for this vulnerability. The patch ensures proper Content-Type headers are set for JSON responses, preventing browsers from interpreting the response as HTML.

Patch details are available in the GitHub commit and the updated release can be obtained from the GitHub Release v8.0.0.3.

For complete vulnerability details, refer to the GitHub Security Advisory GHSA-wwhf-6cvc-6766.

Workarounds

• Implement a Web Application Firewall (WAF) rule to filter XSS payloads in the title POST parameter
• Configure web server or reverse proxy to force Content-Type: application/json headers for JSON API endpoints
• Apply input validation at the web server level to sanitize or reject requests containing HTML/script tags in sensitive parameters
• Restrict access to vulnerable endpoints to trusted IP ranges while awaiting patching

# Example Apache configuration to set proper Content-Type for JSON responses
# Add to .htaccess or VirtualHost configuration
<FilesMatch "\.php$">
    <If "%{QUERY_STRING} =~ /format=json/ || %{REQUEST_URI} =~ /api/">
        Header set Content-Type "application/json; charset=UTF-8"
    </If>
</FilesMatch>