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:

An authenticated attacker with Notes - my encounters role navigates to a patient encounter
The attacker fills out an Eye Exam form and inserts malicious JavaScript in one or more form fields
The payload is stored in the database without proper sanitization
When another user with the same role views the encounter page or visit history, the stored payload is retrieved and rendered without proper encoding
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

bash

# 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>