CVE-2026-33348: OpenEMR Stored XSS Vulnerability

CVE-2026-33348 Overview

OpenEMR, a widely-used free and open source electronic health records (EHR) and medical practice management application, contains a stored cross-site scripting (XSS) vulnerability in the Eye Exam form display functionality. Users with the Notes - my encounters role can fill Eye Exam forms in patient encounters, and the form answers are displayed on the encounter page and visit history. Versions prior to 8.0.0.3 fail to properly sanitize user input, allowing authenticated attackers with the specific role to inject arbitrary JavaScript into the system through malicious form answer payloads.

Critical Impact
Authenticated attackers can inject persistent JavaScript payloads that execute in the browser context of any user viewing patient encounter pages or visit history, potentially leading to session hijacking, credential theft, or unauthorized actions within the healthcare system.

Affected Products

OpenEMR versions prior to 8.0.0.3
OpenEMR installations with Notes - my encounters role enabled
Healthcare organizations using OpenEMR Eye Exam form functionality

Discovery Timeline

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

Technical Details for CVE-2026-33348

Vulnerability Analysis

This stored XSS vulnerability (CWE-79) exists in the function responsible for displaying Eye Exam form answers within OpenEMR. The application fails to properly sanitize or encode user-supplied input before rendering it in HTML context, allowing malicious JavaScript to be persisted in the database and later executed when other users view the affected pages.

The vulnerability requires authentication with the Notes - my encounters role, which provides access to fill Eye Exam forms. Once an attacker submits a form containing malicious JavaScript in the answer fields, the payload is stored and subsequently rendered without proper encoding when any user with form access views the patient encounter pages or visit history.

In healthcare environments, this vulnerability poses significant risks including potential exposure of protected health information (PHI), session hijacking of privileged users, and the ability to perform unauthorized actions under the context of victim users.

Root Cause

The root cause of this vulnerability is insufficient input validation and output encoding in the Eye Exam form answer display functionality. The application accepts arbitrary input in form answer fields and renders this content directly in the HTML response without proper sanitization, allowing script tags and JavaScript event handlers to execute in the user's browser context.

Attack Vector

The attack requires network access and low-privilege authentication with the Notes - my encounters role. An attacker can exploit this vulnerability by:

Authenticating to OpenEMR with a user account possessing the Notes - my encounters role
Navigating to a patient encounter and accessing the Eye Exam form
Entering malicious JavaScript payloads in form answer fields (e.g., <script> tags or event handlers)
Submitting the form, causing the malicious payload to be stored in the database
When any user with form access views the encounter page or visit history, the JavaScript executes in their browser

The vulnerability does not require user interaction beyond normal application use, as the malicious code executes automatically when viewing affected pages. Technical details and the specific fix can be found in the GitHub Security Advisory.

Detection Methods for CVE-2026-33348

Indicators of Compromise

Unusual JavaScript code or HTML tags present in Eye Exam form answer database fields
Unexpected network requests originating from OpenEMR pages to external domains
User session cookies being transmitted to unauthorized endpoints
Anomalous user behavior patterns following access to patient encounter pages

Detection Strategies

Monitor web application logs for suspicious form submissions containing script tags or JavaScript event handlers
Implement Content Security Policy (CSP) headers to detect and block inline script execution
Deploy web application firewall (WAF) rules to identify XSS payload patterns in form submissions
Review database records for Eye Exam form answers containing potentially malicious content

Monitoring Recommendations

Enable detailed logging for all form submissions within OpenEMR
Configure alerts for CSP violation reports indicating blocked script execution attempts
Monitor for unusual session activity or authentication patterns following encounter page access
Implement browser-based monitoring to detect unexpected DOM modifications or script execution

How to Mitigate CVE-2026-33348

Immediate Actions Required

Upgrade OpenEMR to version 8.0.0.3 or later immediately
Audit existing Eye Exam form data for potentially malicious content
Review access logs for users with Notes - my encounters role for suspicious activity
Consider temporarily restricting Eye Exam form access until patching is complete

Patch Information

OpenEMR has released version 8.0.0.3 which contains the security fix for this vulnerability. The patch implements proper output encoding for form answer display, preventing JavaScript execution from user-supplied input. Organizations should upgrade to this version as soon as possible. The specific commit addressing this vulnerability is available at the GitHub Commit, and the patched release can be obtained from GitHub Release v8.0.0.3.

Workarounds

Implement a web application firewall (WAF) with XSS detection rules to filter malicious input
Deploy Content Security Policy headers with strict script-src directives to prevent inline script execution
Restrict the Notes - my encounters role to only trusted personnel until patching is complete
Consider disabling the Eye Exam form functionality temporarily in high-risk environments

bash

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