DICOM Fuzzing for Medical Devices: What to Test

DICOM parsers are some of the oldest code in a hospital. Many imaging devices still embed C and C++ toolkits whose core parsing logic was written decades ago, and they accept input from any system on the imaging network.

That code keeps producing serious bugs. In 2026, CISA advisory ICSMA-26-181-01 listed five vulnerabilities in the OFFIS DCMTK toolkit, versions 3.7.0 and earlier, including path traversal, memory exhaustion, and type confusion, with a CVSS v3 score of 9.8.

DICOM fuzzing is how you find bugs like these in your own device first. This post covers which parts to fuzz, how to build a fuzzer that understands DICOM, and how to tell a real crash from noise.

Why This Matters

The FDA's Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions final guidance (February 3, 2026) lists fuzz testing among the security testing it expects in a premarket submission, alongside penetration testing, vulnerability scanning, and abuse case testing. For an imaging device, DICOM is usually the largest input surface, so it is where fuzzing effort pays off most.

The risk is not theoretical. CISA's ICSMA-26-181-01 advisory describes DCMTK flaws that let an attacker write files outside the intended folder, exhaust memory, or crash client and server processes. Any device that embeds an affected DCMTK version inherits those flaws, whether or not the manufacturer wrote a line of parsing code.

A crashed imaging service means delayed reads and repeated scans. A parser bug that allows code execution puts the device, and every system that trusts it, under an attacker's control.

Fuzzing also supports the standards your submission already relies on. IEC 81001-5-1 includes security testing such as fuzzing in its verification activities, ANSI/AAMI SW96 expects security risk controls to be verified, and the DICOM standard itself (NEMA PS3) defines the exact structures your fuzzer should bend. For the general method, see our fuzz harness generation guide for medical device protocols.

Which parts of DICOM should you fuzz?

Fuzz every place your device parses DICOM data it did not create. In practice that means three layers, plus any web interface that handles images.

Two areas get missed most often. The first is pixel data decoders: compressed images go through separate JPEG, JPEG-LS, or JPEG 2000 libraries, which have their own advisories. The second is the client side: if your device retrieves images with C-GET or C-MOVE, a malicious server can attack it, as one of the ICSMA-26-181-01 issues showed.

The DICOM protocol vulnerabilities post explains how these weaknesses are exploited in practice, and Hacking DICOM: medical imaging security risks covers the preamble and file-based attacks.

How do you build a DICOM-aware fuzzer?

A DICOM-aware fuzzer changes one field at a time while keeping the rest of the message valid, so the input gets past the first length check. Random bytes are rejected at the PDU header and never reach the code that matters.

A practical setup has four parts:

1. Seed corpus. Real, de-identified images from every modality and transfer syntax the device supports, plus captured association traffic.
2. Structure model. A grammar of PDUs and data elements (tag, value representation, length, value) so mutations land in specific fields. Tools such as boofuzz or a custom libFuzzer harness work well here.
3. Fixups. After a mutation, recalculate the lengths that should stay correct, and deliberately leave others wrong to test length handling.
4. State. Network fuzzing has to complete association setup before sending DIMSE commands, then release or abort cleanly between test cases.

Where you have source code, compile the parser with AddressSanitizer and fuzz it in-process with coverage guidance. Where you only have the device, fuzz over the network and watch the device closely, as described below.

How do you prove a DICOM crash is real?

A finding is real when a saved input reproduces it, and a tool shows the exact fault. Everything else is a lead, not a result.

Network fuzzing produces a lot of false alarms. A device that drops the connection may be correctly rejecting bad input, rate limiting, or restarting a worker process by design. Use this checklist before reporting anything:

The health check matters most. Sending a C-ECHO after every test case is a simple way to see whether the service is still alive. If it times out, record the last inputs sent and replay them one at a time.

Need DICOM fuzzing on your device? Our team builds DICOM-aware fuzzers and triages every crash as part of medical device penetration testing.

What evidence does the FDA expect from fuzz testing?

Reviewers want enough detail to judge whether the fuzzing was thorough and whether findings were handled. A sentence saying "fuzz testing was performed" does not meet that bar.

Include:

• Scope: which DICOM services, roles (server and client) and transfer syntaxes were fuzzed, and which were not, with reasons.
• Method: tools, how inputs were generated, test duration, and number of test cases.
• Coverage: code coverage where source was available, or the list of fields and commands mutated where it was not.
• Findings: each crash with its reproduction status, root cause, severity, and fix or justification.
• Traceability: links from each finding to the threat model entry and security risk assessment it affects.

DICOM toolkits and image codecs also belong in the SBOM with exact versions, so that a future advisory can be matched to the device within days rather than weeks.

How Blue Goat Cyber Approaches This

We start from the device's DICOM conformance statement, which tells us every service, role, and transfer syntax the device claims to support. That becomes the fuzzing scope, and anything the device does that is not in the statement becomes a finding of its own.

We build seed corpora from the device's own modalities, fuzz association setup, DIMSE commands, the file format, and DICOMweb where present, and run a health check after every test case. Where firmware or source is available, we also fuzz the parser directly with memory checking turned on.

Every crash is reproduced, minimized, and located before it reaches the report, with a clinical impact statement and a retest after the fix. Our team has supported 275+ devices through FDA cybersecurity work. Fuzzing is part of our medical device penetration testing, and if the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost.

Frequently Asked Questions

What is DICOM fuzzing?

DICOM fuzzing is a security test that sends large numbers of malformed DICOM network messages and image files to a device to find parser bugs. A good DICOM fuzzer understands the protocol structure, so it changes one field at a time while keeping the rest valid. That lets the bad input reach deep parsing code, where crashes, memory corruption, and path traversal bugs are usually found.

Which DICOM services should be fuzzed first?

Start with whatever the device exposes to the network without authentication, which is usually association setup and C-STORE, because any system on the imaging network can reach them. Then cover C-FIND, C-MOVE, and C-GET, and the file format inside stored objects. If the device retrieves images from other systems, fuzz its client role too, since a malicious server can send it bad data.

Is a dropped connection during fuzzing a vulnerability?

Not necessarily, and treating every disconnect as a crash is a common mistake. A device may drop a connection because it correctly rejected bad input. A real finding reproduces from a saved input on a freshly restarted device, and a memory tool, debugger, crash log, or failed health check shows the service actually failed rather than refused the message.

Does the FDA require fuzz testing for imaging devices?

The FDA's February 2026 premarket cybersecurity guidance lists fuzz testing as one of the security tests it expects to see in a submission. It does not prescribe a specific tool or duration. For an imaging device, reviewers will expect the DICOM interfaces to be covered, with the scope, method, findings, and fixes documented and traced to the threat model.

Do we need to fuzz DICOM if we use an open-source toolkit?

Yes. Using DCMTK, GDCM, dcm4che, or another toolkit does not remove the risk; it moves it into your SBOM. Toolkits regularly receive advisories, such as CISA's ICSMA-26-181-01 for DCMTK in 2026, and your own code around the toolkit can add new bugs. Fuzzing tests the whole parsing path as it actually runs in your device.

CTA

Need DICOM fuzzing that holds up to FDA review, with every crash reproduced and explained? Request a quote for medical device penetration testing. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost.

---

Christian Espinosa, MBA, CISSP, Founder and CEO, Blue Goat Cyber. Christian has led penetration testing programs for connected medical devices, including imaging systems where DICOM services were the main attack surface. He previously led military red-team operations. Read more about Christian.