CISA spent the summer working through the DICOM stack

MedDevice Cyber Staff · Aug 11 · 4 min read · Via CISA

Four ICS medical advisories this year target open source DICOM components. GDCM (ICSMA-26-083-01). pydicom and pynetdicom (ICSMA-26-176-01). The OHIF viewer framework (ICSMA-26-176-02). OFFIS DCMTK (ICSMA-26-181-01).

Study the OHIF one. CVE-2026-12473, CVSS 8.2. Two default data sources fetch an arbitrary URL without validation, and the auth layer injects the user’s OIDC bearer token into requests to whatever server an attacker names. Token theft by crafted link. Fixed in 3.12.2. Credit to Simon Weber and Volker Schönefeld of Machine Spirits UG. DCMTK adds a path traversal, CVE-2026-50003.

The OHIF weakness illustrates a hazard specific to web-based imaging viewers. When a viewer fetches a destination it was handed without checking whether it should be trusted, and attaches the signed-in user's token to the request, a crafted link can send that credential to a server the attacker controls.

If you build or buy imaging, these libraries are in your SBOM whether you know it or not. Philips put out its own DCMTK advisory on July 8. That’s the downstream obligation in action: assess, disclose, patch, even when the bug was never yours.

An advisory against an upstream library behaves differently from one against a finished product, because the vulnerable code has no single operator. The same framework sits inside many vendors' systems at once, each integrating it differently, so one flaw becomes many separate exposures. A fix reaches patients only after each embedding product ships.

The clustering of these notices across the year signals sustained scrutiny of the formats and services carrying medical images. Disclosure on shared code sets off a sequence: the upstream project is notified, a coordinating authority publishes, and each manufacturer that embedded it assesses and answers in turn. The advisories that surface are the visible edge of a larger reconciliation inside each vendor.

Component intake is the job now. A CISA advisory on an open source library is the starting gun for yours. Makers with working intake pipelines publish while everyone else is still grepping SBOMs.

Remediation Desk

For ProvidersOperators, hospitals, and clinical engineering

The advisories landed in shared imaging libraries, not in one vendor product, so the fix is an SBOM exercise. Map GDCM, pydicom, OHIF and DCMTK to every product that embeds them, then patch or pin to fixed versions and re-issue the affected builds.

Resolve the libraries in your SBOM. Find every product that bundles GDCM, pydicom, OHIF or DCMTK, including transitive dependencies you did not add directly.
Patch to fixed upstream versions. Track each advisory to the upstream fix commit and rebuild affected products against it.
Subscribe to upstream security feeds. The imaging plumbing is maintained elsewhere, so watch the upstream projects, not just your own code, for the next advisory.

For Device ManufacturersAm I affected, and how to fix the class

Am I affected?

This class applies to devices with the properties below. Check them against your product to gauge exposure.

Required

parse_image

Contributing

sys_ots_software app_web_ui net_cloud app_user_accounts net_remote_access data_phi use_hospital_net

EMB3D

PID-23 PID-26

Fix the class in your product

The advisory is not for a bug you wrote; it is in a component you embed. As the maker, pin dependencies to fixed versions, generate an SBOM on every build including transitive components, and gate the pipeline on known-vulnerable components so an advisory maps to your products automatically.

Pin and inventory. Exact versions, and a CycloneDX or SPDX SBOM as a build artifact including transitive deps.
Gate on advisories. A CI scan fails a release carrying a component with a known advisory.
Own the field patch path. Know how you deliver a dependency or platform patch to fielded devices before you need it.

Mapped EMB3D mitigations

← Back to Vulnerabilities