CVE-2026-25860: OpenClinic GA XSS Vulnerability

CVE-2026-25860 Overview

CVE-2026-25860 is a reflected cross-site scripting (XSS) vulnerability in OpenClinic GA 5.351.19, an open-source hospital and healthcare information management system. The flaw resides in the DICOM image upload handler, where metadata fields embedded inside DICOM files are reflected back to users without sanitization. Attackers craft a DICOM file containing JavaScript payloads in metadata fields such as Study Description, then deliver it through the Upload DICOM images feature. The payload executes when the file is processed through popup.jsp and archiving/uploadfiles_jsp.java. The weakness is classified under CWE-79: Improper Neutralization of Input During Web Page Generation.

Critical Impact
Successful exploitation lets attackers execute arbitrary JavaScript in a clinician's browser session, enabling session theft, UI manipulation, and a documented XSS-to-RCE pivot chain demonstrated by external researchers.

Affected Products

OpenClinic GA 5.351.19
DICOM image upload handler component (popup.jsp)
DICOM archiving component (archiving/uploadfiles_jsp.java)

Discovery Timeline

2026-06-09 - CVE-2026-25860 published to NVD
2026-06-10 - Last updated in NVD database

Technical Details for CVE-2026-25860

Vulnerability Analysis

The vulnerability stems from improper neutralization of user-controlled metadata embedded in Digital Imaging and Communications in Medicine (DICOM) files. OpenClinic GA accepts DICOM uploads through its archiving workflow and renders selected metadata tags inside JSP-rendered HTML responses. The application reflects these fields directly into the page without applying output encoding or HTML entity escaping.

Because DICOM metadata tags such as Study Description, Patient Name, and Referring Physician accept free-form text, an attacker can embed <script> tags or event-handler payloads in those fields. When a clinician or administrator views the uploaded image through the affected pages, the browser parses and executes the embedded JavaScript. External research published by Partywave documents how this XSS primitive can be chained with other OpenClinic GA weaknesses to achieve remote code execution on the server.

Root Cause

The root cause is missing output encoding in popup.jsp and archiving/uploadfiles_jsp.java. The JSP code reads DICOM metadata strings from the parsed file and writes them into the HTML response context using unescaped expression output. There is no HTML entity encoding, no Content Security Policy enforcement, and no input validation against script-bearing characters before rendering.

Attack Vector

The attack is delivered over the network and requires user interaction. An attacker prepares a malicious DICOM file with JavaScript embedded in a metadata field, then either uploads it directly when authenticated or convinces an authenticated user to upload it. When the file metadata is rendered in the upload confirmation or archive view, the payload runs in the victim's browser under the OpenClinic GA origin. The attacker can then exfiltrate session cookies, perform actions on behalf of the victim, or stage follow-on exploitation as described in the public proof-of-concept at partywavesec/CVE-2026-25860.

No verified code examples are available. Refer to the Partywave Research Article and the VulnCheck Security Advisory for full technical details and the XSS-to-RCE chain.

Detection Methods for CVE-2026-25860

Indicators of Compromise

DICOM files uploaded to OpenClinic GA that contain <script>, onerror=, onload=, or javascript: substrings in metadata tags such as Study Description or Patient Name.
HTTP requests to popup.jsp or archiving/uploadfiles_jsp.java returning responses with unescaped angle brackets in reflected metadata.
Unexpected outbound HTTP requests from clinician browser sessions immediately following DICOM archive views.

Detection Strategies

Inspect uploaded DICOM file metadata at ingestion using a DICOM parser and flag tags containing HTML or JavaScript syntax.
Deploy a web application firewall rule that blocks responses from OpenClinic GA upload endpoints when reflected payloads contain script delimiters.
Review application logs for repeated uploads from the same authenticated session followed by abnormal session token use from new IP addresses.

Monitoring Recommendations

Forward OpenClinic GA web server access and application logs to a centralized analytics platform and alert on requests to popup.jsp containing suspicious query parameters or referrer chains.
Monitor endpoint telemetry on workstations used by clinical staff for browser-driven credential or token exfiltration patterns.
Track DICOM upload volume and file size anomalies, since weaponized files often deviate from clinical baselines.

How to Mitigate CVE-2026-25860

Immediate Actions Required

Restrict access to the DICOM upload feature to authenticated, trusted users on segmented networks only.
Place OpenClinic GA 5.351.19 behind a reverse proxy or web application firewall that strips or encodes HTML metacharacters in responses from the affected JSP endpoints.
Audit recent DICOM uploads for metadata containing script tags or JavaScript URIs and quarantine matching files.

Patch Information

No vendor patch is referenced in the available CVE data. Monitor the OpenClinic GA project and the VulnCheck Security Advisory for fix availability. Until an official update is released, apply the workarounds below and validate that DICOM metadata is sanitized before rendering.

Workarounds

Pre-process all incoming DICOM files with a sanitization script that strips or HTML-encodes characters such as <, >, ", ', and & from text-value metadata tags before storage.
Enforce a strict Content Security Policy on OpenClinic GA responses that disallows inline scripts, reducing the impact of reflected payloads.
Disable the DICOM Upload images feature for users who do not require it, and remove the popup.jsp endpoint from external exposure.

bash

# Configuration example: nginx CSP header for OpenClinic GA reverse proxy
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-XSS-Protection "1; mode=block" always;