Blue Goat CyberSMMedical Device Cybersecurity
    K
    Blog · IoT & Connected Devices

    Hacking DICOM Medical Images

    Digital Imaging and Communications in Medicine, or DICOM, is the industry standard for medical imaging formats.

    Hero illustration for the IoT & Connected Devices article: Hacking DICOM Medical Images
    Christian Espinosa, Founder & CEO at Blue Goat Cyber

    By Christian Espinosa, MBA, CISSP

    Founder & CEO · Blue Goat Cyber

    Published: March 24, 2024 · Last reviewed: May 1, 2026

    Hacking DICOM Medical Images

    Direct answer

    DICOM (Digital Imaging and Communications in Medicine) presents unique cybersecurity challenges due to its specialized format for medical images and patient data. Vulnerabilities include preamble attacks that exploit file conversion features for malware delivery, and server misconfigurations such as internet exposure, weak authentication, and unencrypted data transmission. Securing DICOM requires strict network segmentation, strong authentication, TLS encryption for data transfers, and vigilant scanning for malicious file preambles.

    Digital Imaging and Communications in Medicine, or DICOM, is the industry standard for medical imaging formats. This format has expanded functionality compared to typical image formats, as it can store patient data and procedure information along with the actual image. Typically, a specialized DICOM server will parse DICM files, or a Picture Archiving and Communication System (PACS) server. This data can be passed physically on a CD or drive, or digitally via TCP. DICOM images also have support for transfer to more common image formats, such as PNG.

    Key Takeaways

    • DICOM files store sensitive patient and procedure data.
    • Preamble attacks can embed malware in DICOM files.
    • DICOM servers often share common web server vulnerabilities.
    • Misconfigurations expose DICOM servers to risks and data exfiltration.
    • Strong authentication and encryption are critical for DICOM security.
    • Antivirus should scan DICOM files, quarantining suspicious ones.

    Hacking DICOM Images

    Security researchers may not be as familiar with DICOM as with other protocols due to the narrow use cases and lack of application in day-to-day life outside of the medical field. This is a double-edged sword, as it means that hackers will typically understand it poorly, but it also means the same for defenders. The DICOM format rarely changes due to the massive overhaul that would be needed in hospitals around the world.

    By nature of being used for medical imaging, DICOM files store extremely sensitive data. Regulations such as HIPAA have strict guidelines for how medical data is processed. With more well-understood formats, such as PDF or DOCX files, these guidelines may be more straightforward. This is just since far more people are comfortable with these files. DICOM files may be handled improperly far more frequently.

    There are many different tools available for processing DICOM files to perform some sort of analysis. This analysis is often done on the image itself to identify potentially dangerous results, such as imaging to detect cancer. When processing like this is done, a commonly forgotten step is anonymizing data. This prevents files from being compromised and patient data from being leaked to the attackers.

    A vulnerability specific to the DICOM format is preamble attacking. The DICOM preamble is a section of the file that facilitates transfers to other file formats. This is intended for transfer to other image formats, but it is possible to run executable files through DICOM images. An extremely dangerous part about this is the fact that antivirus is often told to avoid DICOM files due to the risk of PHI getting deleted. This means that attackers can often supply malware through DICOM files without getting detected.

    Hacking DICOM Servers

    DICOM servers are prone to a myriad of vulnerabilities and misconfigurations. Similar to many other file-share systems, data mishandling is pervasive. DICOM servers need to be well-hardened against attacks to prevent regulatory breaches. Aside from compliance problems, compromise of DICOM files can result in customer distrust. This can be damaging to the image and identity of the company.

    In many cases, DICOM servers operate in a similar way to traditional web servers. This means that they are commonly associated with the same vulnerabilities that web servers are associated with. CVEs are regularly assigned to various DICOM servers as vulnerabilities are discovered. Many of these can be extremely dangerous, such as remote command execution or various buffer overflows. Not only will these vulnerabilities lead to compromise of the DICOM server, but they may lead to lateral movement into the internal network.

    Misconfigurations are common in DICOM servers. DICOM servers may be exposed to the internet where attackers can attempt to interact with them. If the specific server has known vulnerabilities, this can lead to easy access to the internal network. There are rarely good reasons to expose these servers. Even if the server is fully patched, certain misconfigurations can lead to dangerous situations.

    DICOM servers support queries to pass in or pull out data. This allows for seamless transfer of information within a hospital, but when servers are exposed, it may be possible for hackers to extract data. These servers commonly have no form of authentication or very weak authentication. It is often trivial for hackers to simply query the server and receive sensitive patient data.

    Another flaw that may be found in DICOM servers relates to how data is processed. Some servers may be configured to pass data over plaintext. When this is the case, a hacker would just need to be in a position to sniff network traffic and they could intercept DICOM transfers and see patient data in the clear. DICOM servers should always be configured to use TLS when transferring data for maximum security.

    Notable DICOM and PACS Vulnerabilities

    A handful of CVEs illustrate why DICOM and PACS deployments deserve sustained scrutiny rather than a one-time pen test:

    • CVE-2019-11687 (Orthanc) - authentication bypass in the popular open-source DICOM server when the REST API was exposed without credentials.
    • CVE-2020-11176 / CVE-2020-11175 (DCMTK) - heap-based buffer overflow and out-of-bounds read in the widely-embedded DCMTK toolkit; reachable through crafted DICOM associations.
    • CVE-2022-1080 (Horos / Osirix lineage) - DICOM parser memory corruption affecting viewer software used in research and clinical settings.
    • HDG-201801 / "PwnedPiper" class issues - research from Shodan-based scans has repeatedly shown thousands of internet-exposed DICOM endpoints leaking studies and PHI without authentication.

    The pattern is consistent: parser bugs in long-lived C/C++ toolkits (DCMTK, GDCM, dcm4che) plus default-open network services. Both vectors land squarely inside the FDA's expectations for SBOM disclosure and postmarket vulnerability management.

    DICOM and the FDA's 524B Expectations

    Under Section 524B and the February 3, 2026 premarket cybersecurity guidance, any cyber device that speaks DICOM (imaging modalities, viewers, AI inference servers, PACS gateways) needs to demonstrate that DICOM-specific risks are accounted for in the submission, not just generic network controls. Reviewers commonly look for:

    • Threat model coverage - DICOM C-STORE, C-FIND, C-MOVE, and WADO interfaces enumerated as trust boundaries with explicit STRIDE entries.
    • SBOM precision - exact versions of DCMTK, GDCM, dcm4che, Orthanc, or pynetdicom, including transitive dependencies, with VEX statements for any unpatched CVEs.
    • Authentication posture - TLS with mutual authentication (DICOM TLS profile) or evidence that the device is constrained to a segmented imaging VLAN with compensating controls.
    • Preamble / parser hardening - fuzzing evidence against the DICOM parser, antivirus integration that does not blanket-exclude .dcm, and monitoring for non-imaging preamble magic numbers.
    • Postmarket monitoring - a documented process for tracking CVEs in the DICOM stack and pushing patches within the timelines committed to in the submission.

    If you have seen the FDA flag DICOM specifically in a deficiency letter, it is almost always one of these five buckets. Our FDA Cybersecurity Deficiency Letter examples guide walks through how these come back worded in practice.

    Securing DICOM - Practical Checklist

    DICOM files should be monitored for malicious preambles. The preamble will be the first bytes of the file with the first four dictating what the file is meant to be transformed to. Seeing anything besides known imaging formats should immediately set off alarms that something is off. DICOM files should also be scanned by antivirus software. To prevent patient data from being deleted, questionable files should be flagged and quarantined.

    Any DICOM servers should be confined to the internal network. There will rarely be situations where it is a good idea to leak them to the open internet. Even internal servers should be fully kept up to date and transfer data over encrypted communication channels. This prevents further compromise if an attacker gets into the internal network through other means. DICOM servers should also be configured to use appropriate authentication.

    Concretely, for a device or PACS deployment that needs to hold up under FDA review and a hospital security questionnaire:

    1. Enforce the DICOM TLS profile (or wrap C-STORE in mTLS via a gateway) - never run plaintext DIMSE over routable networks.
    2. Require AE Title plus user-level authentication; disable anonymous queries on C-FIND / C-MOVE.
    3. Segment imaging modalities and PACS onto a dedicated VLAN with allow-list firewall rules between modality, PACS, viewer, and any AI inference service.
    4. Patch DCMTK / GDCM / dcm4che / Orthanc on the same cadence as your OS - track them in your SBOM and publish a VEX entry for any CVE you are not patching.
    5. Scan inbound DICOM with malware tooling that inspects the preamble; alert on any preamble that is not a known imaging signature.
    6. Log every association, query, and retrieve to a SIEM; PHI exfiltration via C-MOVE is otherwise invisible.
    7. Fuzz your own DICOM parser (or your vendor's) - most exploitable bugs in this space are reachable from a single malformed dataset.

    Check out our medical device cybersecurity FDA compliance package or our medical device penetration testing service if you need an external team to validate the DICOM attack surface on your device or PACS deployment.

    FAQs

    What is DICOM used for?

    DICOM (Digital Imaging and Communications in Medicine) is the standard for medical imaging. It stores images, patient data, and procedure information, facilitating communication between medical devices and systems.

    How can DICOM files be exploited?

    DICOM files can be exploited through 'preamble attacking,' where malicious executable code is hidden within the file's preamble, bypassing traditional antivirus scans that often exempt DICOM files due to PHI deletion concerns.

    Why are DICOM servers vulnerable?

    DICOM servers are vulnerable due to common web server weaknesses, misconfigurations like internet exposure, weak or absent authentication, and unencrypted data transmission, leading to data breaches and network compromise.

    Does the FDA regulate DICOM security?

    The FDA expects medical device manufacturers to address cybersecurity for all components, including those utilizing DICOM. The February 3, 2026 final guidance outlines expectations for securing medical devices throughout their lifecycle.

    What is a DICOM preamble attack?

    A DICOM preamble attack involves embedding malware in the file's preamble, a section used for format conversion. This can allow attackers to execute malicious code when the DICOM file is processed.

    How can DICOM servers be secured?

    Secure DICOM servers by confining them to internal networks, implementing strong authentication, enforcing TLS encryption for all data transfers, and regularly patching identified vulnerabilities.

    Related: The Rising Tide of Cyber Threats in Medical Devices: Understanding the Risks

    Related services

    Put this into practice on your device

    Every Blue Goat Cyber engagement maps directly to FDA Section 524B and the SPDF - so the evidence you need lands in your submission, not in a separate report.

    Ready when you are

    Get FDA cleared without the cybersecurity headaches.

    30-minute strategy session. No cost, no commitment - just answers from people who've shipped 250+ FDA submissions.