---

Introduction

In the world of medical imaging, DICOM files and DCMTK are household names. DCMTK is a widely used open-source toolkit for working with DICOM files. But recently, a critical vulnerability—CVE-2025-25475—was found in DCMTK, specifically in the /libsrc/dcrleccd.cc component in version 3.6.9 and newer DEV releases. This security flaw allows attackers to crash a DCMTK-based application simply by feeding it a malicious DICOM file. Let’s break down what’s wrong, how it works, and why it matters.

What is CVE-2025-25475?

CVE-2025-25475 is a NULL pointer dereference vulnerability. This means that a pointer in the program is used without being properly initialized, so it tries to access memory at address —causing a crash. Attackers can use this flaw to perform a Denial of Service (DoS) attack, crashing servers or workstations that process DICOM files with affected DCMTK versions.

Vulnerable component:
/libsrc/dcrleccd.cc in DCMTK v3.6.9+ DEV

The application using DCMTK processes a DICOM file.

2. In certain cases—when the file is manipulated in a specific way—a pointer in /libsrc/dcrleccd.cc is left uninitialized or set to NULL.

Code Snippet: Where Things Go Wrong

Let’s look at a simplified version of the problematic code in dcrleccd.cc (for illustration only):

// in dcrleccd.cc, function: decode()
RLECodecParameter* rleParam = NULL;
...
if (/* malformed DICOM triggers early return, rleParam not set */) {
    // some error triggers exit from function
    return;
}
// Later in the function
processData(rleParam->data); // <-- rleParam may still be NULL!

When rleParam is NULL, calling rleParam->data will crash the program: classic NULL pointer dereference.

Why is This Dangerous?

A typical scenario: a PACS server, teleradiology workstation, or medical image viewer automatically ingests DICOM files sent from various sources. If just one crafted file makes its way into the system, it can crash the entire process, making vital imaging services unavailable.

Let’s walk through an attack

1. Attacker crafts a corrupted DICOM file with payload designed to manipulate how DCMTK allocates or processes structures in /libsrc/dcrleccd.cc.
2. File is uploaded or sent to the target’s DICOM server, which uses the vulnerable DCMTK version.
3. DCMTK tries to decode the RLE-compressed image data, but the file’s structure triggers the bug.

Proof-of-Concept PoC (Python-style pseudocode)

# Create a malformed DICOM file causing rleParam == NULL
with open('dos.dcm', 'wb') as f:
    f.write(b"\x00" * 128)           # DICOM preamble
    f.write(b"DICM")                 # DICOM prefix
    # Insert incorrect RLE compression tag, missing or malformed fragments
    f.write(b"\xFF\xFE\xE\x00...")  # Incorrect RLE header
    # ... make the file appear valid, but triggering the NULL pointer issue

Once this file is processed by a vulnerable DCMTK installation, it will crash.

> Note: A real exploit would require knowledge of the DICOM and RLE format. The above is a conceptual illustration.

Real-World Impact

- Denial of Service (DoS): A remote attacker can knock out image viewers, PACS, or servers by sending a malicious file.
- Potential chain attacks: In a hospital setting, can disrupt diagnosis work, delay treatment, or trigger cascading downtime.

Upgrade DCMTK: Ensure you’re using the latest, patched version.

- Harden file upload/input: Validate DICOM files before processing.

References and Further Reading

- DCMTK Official Site
- CVE Record at NIST NVD (pending)
- Original Commit/Advisory (OFFIS DCMTK GitHub) *(search for “CVE-2025-25475” or relevant commit)*
- Intro to DICOM Security

Conclusion

CVE-2025-25475 shows how even simple code bugs—like a NULL pointer dereference—can have massive operational impact, especially in healthcare environments. If you’re using DCMTK 3.6.9 or newer DEV builds, patch now! And always be careful about what files you let your medical imaging systems handle.

Stay safe, stay updated, and share this post to help secure medical imaging everywhere.


*This content is original and exclusive. For more cybersecurity insights, follow our posts.*

Timeline

Published on: 02/18/2025 23:15:10 UTC
Last modified on: 02/20/2025 22:15:31 UTC