Description

OHIF Viewers is a zero-footprint DICOM viewer with shared extension packages. From 3.5.0-beta.0 until 3.12.15, 3.13.7, and 3.14.0-beta.19, the dicom-pdf extension reads the attacker-controlled MIMETypeOfEncapsulatedDocument value in extensions/dicom-pdf/src/getSopClassHandlerModule.js and uses it as the Blob media type for the attacker-controlled EncapsulatedDocument bytes. When a victim opens Encapsulated PDF SOP Class 1.2.840.10008.5.1.4.1.1.104.1, extensions/dicom-pdf/src/viewports/OHIFCornerstonePdfViewport.tsx embeds the Blob URL in an object element. A Blob labeled as HTML is handled as HTML despite the application/pdf object hint, and the Blob inherits the OHIF origin, allowing embedded script to access session storage, authentication tokens, and same-origin PACS requests. The malicious DICOM object may be opened locally, uploaded to a shared PACS, or supplied by a DICOMweb source. This issue is fixed in source versions 3.12.15, 3.13.7, and 3.14.0-beta.19.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-11-06T18:17:57.340Z",
  "pubdate": "2026-11-06T18:17:57.340Z",
  "executiveSummary": "The OHIF Viewer is susceptible to a Cross-Site Scripting (XSS) vulnerability within the dicom-pdf extension, specifically affecting the handling of Encapsulated PDF SOP Class (1.2.840.10008.5.1.4.1.1.104.1) objects.\nThe vulnerability arises from the improper sanitization of the MIMETypeOfEncapsulatedDocument attribute, which is controlled by the DICOM object. By supplying a malicious MIME type, an attacker can coerce the viewer into interpreting a Blob as HTML rather than PDF, despite being embedded in an object element.\nBecause this Blob inherits the origin of the OHIF application, the injected script executes within the context of the viewer's origin.\nThis allows the attacker to bypass Same-Origin Policy (SOP) protections, granting unauthorized access to sensitive data including session storage, authentication tokens, and the ability to perform authenticated requests to PACS (Picture Archiving and Communication Systems).\nThe vulnerability affects versions 3.5.0-beta.0 through 3.12.14, 3.13.0 through 3.13.6, and 3.14.0-beta.0 through 3.14.0-beta.18. Exploitation is possible if a victim views a malicious DICOM object from an untrusted PACS or DICOMweb source.\nGiven the nature of PACS environments, which often contain highly sensitive Protected Health Information (PHI), this vulnerability poses a critical risk to patient data integrity and confidentiality.",
  "technicalDetails": "The root cause of this vulnerability is improper handling of the MIMETypeOfEncapsulatedDocument attribute within extensions/dicom-pdf/src/getSopClassHandlerModule.js. The application blindly trusts this attribute provided within the DICOM object metadata to define the media type for the resulting Blob.\nIn the exploitation flow, an attacker constructs a malicious DICOM object of the Encapsulated PDF SOP Class (1.2.840.10008.5.1.4.1.1.104.1). Within the object's metadata, the attacker sets the MIMETypeOfEncapsulatedDocument to an HTML/text-based type instead of a PDF MIME type.\nThe extensions/dicom-pdf/src/viewports/OHIFCornerstonePdfViewport.tsx component takes the binary EncapsulatedDocument bytes and creates a browser Blob URL using the attacker-supplied, malicious MIME type. This Blob is then embedded into the DOM via an object element.\nAlthough the code may intend to display a PDF, the browser's rendering engine evaluates the Blob based on the specified MIME type provided by the application. By forcing the MIME type to HTML, the browser treats the binary payload—containing embedded scripts—as an active HTML document. Because the Blob is created using window.URL.createObjectURL within the OHIF application, the resulting object inherits the application's origin.\nThis execution context allows the payload to perform unauthorized operations, including accessing document.cookie (if not protected by HttpOnly flags), local storage, session storage, and making fetch/XHR requests to the PACS backend using the victim's existing credentials.\nAn attacker can deliver this payload by uploading the malicious DICOM file to a PACS accessible by the victim, or by acting as a malicious DICOMweb source. The vulnerability is triggered automatically when a user attempts to view the malformed object in the OHIF Viewer.\nAffected versions include all releases from 3.5.0-beta.0 up to, but not including, the patched versions 3.12.15, 3.13.7, and 3.14.0-beta.19."
}