DICOM Parsing Flaws: Four Viewers, One Root Cause

In the first eight months of 2026, four independently maintained pieces of DICOM medical imaging software each received their own CISA ICS Medical Advisory. Not one vendor having a bad year, four separate codebases: an open source toolkit embedded in countless PACS products, an open source parsing library, a widely deployed open source web viewer, and a commercial desktop viewer. Different maintainers, different vulnerability classes, the same underlying failure mode surfacing again and again.

Four advisories, four codebases, one pattern

OFFIS DCMTK, the toolkit a large share of imaging and PACS products build on whether their own documentation admits it or not, disclosed five vulnerabilities together in June 2026 (CISA ICSMA-26-181-01). The worst, CVE-2026-50003, is a path traversal rated CVSS 9.8, critical. It shipped alongside a second path traversal, two memory leaks, and a type confusion bug, all affecting versions prior to 3.7.0.

Grassroots DICOM (GDCM), the parsing library behind a wide range of imaging applications and PACS systems, disclosed CVE-2026-3650 in March 2026 (CISA ICSMA-26-083-01), CVSS 8.7. A malformed DICOM file carrying non-standard Value Representation types makes the parser allocate memory it never releases, so one crafted file can exhaust a system's memory in a single read.

OHIF Viewers, an open source web based viewer widely deployed as the front end for PACS installations, disclosed CVE-2026-12473 in June 2026 (CISA ICSMA-26-176-02), CVSS 8.2. Its DICOMWebProxy and DICOMJSON data sources fetch attacker supplied URLs without validating them, and in authenticated deployments the viewer can auto attach a logged in clinician's OIDC bearer token to that outbound request. A crafted link, clicked once, hands an attacker a working clinical credential. Fixed in v3.12.2.

Medixant RadiAnt DICOM Viewer, a commercial desktop viewer in wide clinical use, disclosed CVE-2026-17264 in August 2026 (CISA ICSMA-26-218-01), a heap out of bounds write triggered by malicious JPEG compressed pixel data inside a crafted DICOM file, with the potential for arbitrary code execution. Windows exploit mitigations reduce practical exploitability, which is likely why CISA rated it CVSS 4.3 to 5.3, medium, but the underlying parsing flaw is the same category of bug as the others.

Why DICOM parsing keeps breaking

DICOM is a self describing binary format: each element carries a tag, a value representation, a length, and a value, with optional transfer syntaxes and embedded compressed pixel data in formats like JPEG, JPEG 2000, or RLE. A parser has no choice but to trust the length and VR fields declared inside the file it is reading. That is the exact trust boundary each of these four bugs crossed, just in different ways: GDCM's leak came from unexpected VR types, DCMTK's worst bug from type confusion, RadiAnt's from malformed JPEG pixel data triggering a heap write past its buffer. Three decades of accumulated transfer syntax variants, mostly C and C++ implementations, and a format still largely validated by whether a compliant viewer renders it rather than by adversarial fuzzing, is a durable recipe for memory safety bugs.

OHIF's bug is a useful counterpoint, because it is not a memory safety issue at all, it is a logic flaw: trusting a URL parameter enough to auto attach a bearer token to it. The pattern is not limited to old C code. A modern web based viewer reintroduces the same category of problem, an untrusted input treated as safe, in a completely different shape.

Why the usual detection and patching approaches fall short here

A malformed DICOM file that triggers a memory safety bug is not malware. It has no signature to match, because it is data, not code, until a specific vulnerable parser mishandles it. Signature based antivirus has nothing to alert on.

Imaging workstations and PACS servers are frequently reachable from broad hospital IT networks rather than segmented as their own zone, so a compromised viewer is a strong pivot point, not an isolated failure contained to one workstation.

Most hospitals cannot say which DICOM parsing library, or which version of it, sits inside their PACS or viewer software. Checking exposure means asking every imaging vendor individually, not running one internal scan.

DCMTK's own disclosure shows the patching lag concretely: at the time it was reported, the maintainer had applied the fix upstream in the master branch with no official release yet available. A hospital that wanted to patch immediately had nothing shippable to pull in, because a fix landing in source and a fix shipping in the product a vendor actually distributes are two different milestones, often separated by months.

What imaging and security teams can actually do

Ask every imaging and PACS vendor directly which DICOM parsing library, and which version, their product embeds. Do not assume "we did not write DCMTK" means DCMTK is not inside the product, most PACS software is built on exactly these open source components.

Segment imaging workstations and PACS servers as their own network zone, separate from general clinical and business IT, the same zone and conduit thinking IEC 62443 applies to industrial control systems.

Put a validating pre parse or sandboxing step in front of any DICOM ingestion path that accepts studies from outside the trusted network, referring physicians, external imaging centers, patient submitted studies, rather than handing untrusted files straight to the production viewer or PACS ingest pipeline.

Track a fix landing upstream separately from a fix shipping in what is actually deployed. A maintainer committing a fix to source is not the same milestone as a vendor shipping a validated release. Ask vendors for their specific patched version and ship date, not just whether they are aware of the advisory.

For web based viewers, audit any URL fetching data source configuration for credential auto injection, and keep authentication tokens short lived and audience restricted so a leaked token has a short useful life.

Under FDA's Section 524B of the FD&C Act, in effect since March 2023 with premarket guidance finalized in June 2025, device manufacturers already need to document cybersecurity risk management and maintain a software bill of materials. That is precisely the artifact that would let a hospital answer whether it runs a vulnerable DCMTK or GDCM version in minutes, instead of waiting on a vendor phone call. Standalone DICOM tools that are not themselves a regulated medical device, research viewers, referring physician tools, can also fall outside the MDR carve out and squarely into scope for the EU Cyber Resilience Act instead, which is worth an explicit scoping check rather than an assumption. Closing that exact dependency visibility gap, a live, verified record of which parsing libraries and versions sit inside a connected medical product, is the kind of problem Nord CS's Aitigrity platform is built to solve.

Sources:

CISA ICSMA-26-181-01, OFFIS DCMTK Toolkit

CISA ICSMA-26-083-01, Grassroots DICOM (GDCM)

CISA ICSMA-26-176-02, OHIF Viewers DICOM

CISA ICSMA-26-218-01, Medixant RadiAnt DICOM

HIPAA Journal, DCMTK vulnerability disclosure coverage

SentinelOne, CVE-2026-3650 vulnerability record

FDA, Section 524B of the FD&C Act