CVE-2026-32125: OpenEMR Track Anything XSS Vulnerability

CVE-2026-32125 Overview

OpenEMR is a free and open source electronic health records and medical practice management application. A stored Cross-Site Scripting (XSS) vulnerability exists in OpenEMR versions prior to 8.0.0.1 within the Track Anything feature. Track/item names are stored from user input (POST) and later rendered in Dygraph charts (titles/labels) using innerHTML or equivalent without proper escaping. An authenticated user who can create or edit Track Anything items can inject malicious script that executes when any user views the corresponding graph.

Critical Impact

This XSS vulnerability enables authenticated attackers to execute arbitrary JavaScript in the context of other users' sessions, potentially leading to session hijacking, credential theft, or unauthorized access to sensitive patient health records in healthcare environments.

Affected Products

• OpenEMR versions prior to 8.0.0.1
• Track Anything feature component
• Dygraph chart rendering functionality

Discovery Timeline

• 2026-03-11 - CVE CVE-2026-32125 published to NVD
• 2026-03-12 - Last updated in NVD database

Technical Details for CVE-2026-32125

Vulnerability Analysis

This vulnerability is classified as CWE-79 (Improper Neutralization of Input During Web Page Generation), commonly known as Cross-Site Scripting (XSS). The flaw resides in how OpenEMR handles user-supplied input for track and item names within the Track Anything feature.

When a user creates or modifies a Track Anything item, the application stores the name without adequate sanitization. Subsequently, when these names are rendered in Dygraph charts as titles or labels, the application uses innerHTML or an equivalent method that interprets the stored content as HTML rather than treating it as plain text. This allows embedded script tags or event handlers to execute in the browser context of any user who views the affected chart.

The stored nature of this XSS vulnerability makes it particularly concerning in a healthcare environment, as malicious scripts persist in the database and execute whenever any user—including administrators or healthcare providers—views the compromised graph data.

Root Cause

The root cause is insufficient output encoding when rendering user-controlled Track Anything item names in Dygraph chart components. The application fails to escape special HTML characters before inserting the values into the DOM via innerHTML, allowing attackers to break out of the expected text context and inject executable JavaScript code.

Attack Vector

An authenticated attacker with permissions to create or edit Track Anything items can craft a malicious item name containing JavaScript code. When another user navigates to view the Dygraph chart that displays this item, the malicious script executes in their browser session.

The attack requires user interaction (viewing the chart) and authenticated access to the Track Anything feature. Due to the changed scope characteristic, the XSS payload executes in the context of the victim's session rather than the attacker's, potentially affecting users with higher privileges.

Attack flow:

1. Attacker authenticates to OpenEMR with Track Anything editing permissions
2. Attacker creates or modifies a track item with a malicious name containing JavaScript
3. Victim user navigates to view the chart containing the malicious item
4. Malicious JavaScript executes in the victim's browser context
5. Attacker can steal session cookies, perform actions as the victim, or access sensitive data

Detection Methods for CVE-2026-32125

Indicators of Compromise

• Unusual or suspicious Track Anything item names containing HTML tags, script elements, or JavaScript event handlers
• Audit log entries showing creation or modification of Track Anything items with encoded characters or script patterns
• Reports from users experiencing unexpected browser behavior when viewing Track Anything graphs
• Web Application Firewall logs showing blocked XSS patterns in POST requests to Track Anything endpoints

Detection Strategies

• Implement Web Application Firewall (WAF) rules to detect and block XSS patterns in POST parameters targeting Track Anything functionality
• Enable and monitor OpenEMR audit logs for suspicious Track Anything item creation or modification activities
• Deploy Content Security Policy (CSP) headers to detect inline script execution attempts via violation reports
• Conduct regular database scans for Track Anything records containing suspicious HTML or JavaScript patterns

Monitoring Recommendations

• Configure alerting for Track Anything item names matching XSS payload patterns (script tags, event handlers, data URIs)
• Monitor browser-side CSP violation reports for inline script execution attempts
• Review access logs for patterns indicating automated XSS injection attempts
• Implement anomaly detection for unusual Track Anything editing activity from user accounts

How to Mitigate CVE-2026-32125

Immediate Actions Required

• Upgrade OpenEMR to version 8.0.0.1 or later immediately
• Review existing Track Anything items in the database for suspicious content containing script tags or JavaScript
• Implement Content Security Policy headers to mitigate impact of any unpatched instances
• Restrict Track Anything editing permissions to trusted users until patching is complete

Patch Information

OpenEMR has addressed this vulnerability in version 8.0.0.1. Organizations should upgrade to this version or later to remediate the XSS vulnerability. For detailed information about the fix, refer to the GitHub Security Advisory.

Workarounds

• Temporarily disable the Track Anything feature if it is not essential to operations
• Implement a Web Application Firewall (WAF) rule to filter XSS patterns in Track Anything POST parameters
• Add Content Security Policy headers with script-src 'self' to prevent inline script execution
• Restrict user permissions for Track Anything creation and editing to minimize the attack surface
• Conduct a manual audit and sanitize existing Track Anything item names in the database

# Example CSP header configuration for Apache
# Add to OpenEMR's .htaccess or Apache configuration
Header set Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:;"