CVE-2026-33299: OpenEMR Stored XSS Vulnerability

CVE-2026-33299 Overview

A stored cross-site scripting (XSS) vulnerability has been identified in OpenEMR, a free and open source electronic health records (EHR) and medical practice management application. The vulnerability exists in the Eye Exam form functionality, where users with the Notes - my encounters role can inject malicious JavaScript code through form answers that get stored and later executed when other users view the patient encounter pages or visit history.

Critical Impact

Authenticated attackers can inject arbitrary JavaScript code that executes in the context of other healthcare practitioners' sessions, potentially leading to session hijacking, credential theft, and unauthorized access to sensitive patient health records.

Affected Products

• OpenEMR versions prior to 8.0.0.2
• Eye Exam form functionality within patient encounters
• Users with Notes - my encounters role access

Discovery Timeline

• 2026-03-19 - CVE CVE-2026-33299 published to NVD
• 2026-03-19 - Last updated in NVD database

Technical Details for CVE-2026-33299

Vulnerability Analysis

This stored XSS vulnerability (CWE-79) affects the Eye Exam form display functionality in OpenEMR. The application fails to properly sanitize and encode user-supplied input when rendering form answers on the encounter page and visit history views. When an authenticated user with the Notes - my encounters role submits an Eye Exam form containing malicious JavaScript payloads, the application stores this unsanitized content in the database. Subsequently, when any user with the same role views the form answers, the malicious script executes within their browser session.

The attack requires network access and user interaction (viewing the compromised form data), but once executed, it can achieve high impact on both confidentiality and integrity of the victim's session. In a healthcare environment, this is particularly concerning as it could allow attackers to access protected health information (PHI) or modify patient records.

Root Cause

The root cause of this vulnerability is improper output encoding in the function responsible for displaying Eye Exam form answers. The application fails to implement proper context-aware output encoding when rendering user-controlled data back to the page, violating secure coding practices for preventing XSS attacks. Specifically, special characters that have meaning in HTML and JavaScript contexts (such as <, >, ", ', and &) are not properly escaped before being inserted into the page's HTML structure.

Attack Vector

The attack follows a stored XSS pattern where the malicious payload persists in the application's database:

1. An authenticated attacker with Notes - my encounters role navigates to a patient encounter
2. The attacker fills out an Eye Exam form and inserts malicious JavaScript in one or more form fields
3. The payload is stored in the database without proper sanitization
4. When another user with the same role views the encounter page or visit history, the stored payload is retrieved and rendered without proper encoding
5. The victim's browser executes the malicious JavaScript in the context of their authenticated session

The vulnerability is particularly dangerous in OpenEMR's healthcare context because it could be used to steal session tokens, exfiltrate patient data, or perform actions on behalf of other healthcare practitioners. For technical details about the vulnerability and its fix, see the GitHub Security Advisory GHSA-pgvq-f22q-2whp.

Detection Methods for CVE-2026-33299

Indicators of Compromise

• Unusual JavaScript code or HTML tags present in Eye Exam form field values in the database
• Suspicious <script>, <img onerror=, <svg onload=, or similar XSS payloads in form submissions
• Unexpected external network requests originating from the OpenEMR application in browser logs
• Reports from users about unexpected behavior when viewing patient encounter pages

Detection Strategies

• Implement web application firewall (WAF) rules to detect common XSS payload patterns in form submissions
• Enable and monitor application logs for form submissions containing script tags or event handlers
• Deploy content security policy (CSP) headers with strict directives to detect and block inline script execution
• Utilize browser-based XSS auditors and monitoring tools to detect reflected or stored XSS attempts

Monitoring Recommendations

• Monitor database entries for Eye Exam forms for anomalous content patterns indicative of XSS payloads
• Review web server access logs for suspicious form submission patterns targeting encounter pages
• Implement real-time alerting for CSP violations that may indicate XSS exploitation attempts
• Conduct periodic security audits of stored form data to identify potentially malicious content

How to Mitigate CVE-2026-33299

Immediate Actions Required

• Upgrade OpenEMR to version 8.0.0.2 or later immediately
• Review existing Eye Exam form entries in the database for potential malicious payloads
• Implement Content Security Policy (CSP) headers to provide defense-in-depth against XSS
• Temporarily restrict access to the Notes - my encounters role to trusted users only until patching is complete

Patch Information

OpenEMR has addressed this vulnerability in version 8.0.0.2. The fix implements proper output encoding for form answer data when rendering on encounter pages and visit history views. The specific commit addressing this issue is available at the GitHub Commit Reference.

Organizations should prioritize upgrading to the patched version, especially given the sensitive nature of healthcare data handled by OpenEMR. Review the GitHub Security Advisory GHSA-pgvq-f22q-2whp for additional details.

Workarounds

• Implement strict Content Security Policy headers that disallow inline scripts: Content-Security-Policy: script-src 'self'
• Deploy a web application firewall (WAF) with rules to block common XSS payload patterns in form submissions
• Restrict the Notes - my encounters role to only essential personnel until the patch can be applied
• Regularly audit Eye Exam form data for suspicious content and sanitize any discovered malicious entries

# Example Apache configuration for CSP headers
<IfModule mod_headers.c>
    Header set Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; font-src 'self'; frame-ancestors 'self';"
    Header set X-Content-Type-Options "nosniff"
    Header set X-XSS-Protection "1; mode=block"
</IfModule>