Your DICOM Library Is Leaking Memory and Nobody Told You

Let me walk you through a simple attack. You craft a DICOM file. Not a real medical image - just a file that looks like one. You stick some non-standard VR types in the file meta information header, the kind of garbage that a well-behaved parser should reject and move on from. Then you send it to a hospital's PACS server, or slip it into an imaging workflow through a referring facility, or attach it to a study transfer over C-STORE.

The GDCM library on the other end starts parsing your file. It allocates memory for the malformed fields. It never frees it. Send enough of these files and the system starts choking. Memory fills up. The imaging pipeline grinds to a halt. Radiologists can't pull up studies. CT scans queue up with nowhere to go. And you didn't need a single credential to make it happen.

That's CVE-2026-3650. CVSS 8.7. Published March 27, 2026. CISA thought it was serious enough to issue a dedicated medical advisory - ICSMA-26-083-01.

What's GDCM and Why Should You Care

Grassroots DICOM - GDCM - is an open-source C++ library for reading, writing, and manipulating DICOM files. It handles every compression format you'd see in a medical imaging pipeline: RAW, JPEG, JPEG 2000, JPEG-LS, RLE, deflated transfer syntax. It has bindings for Python, C#, Java, and PHP. It supports SCU network operations - C-ECHO, C-FIND, C-STORE, C-MOVE - the fundamental verbs of DICOM networking.

If you run a hospital, there's a reasonable chance GDCM is somewhere in your imaging stack. It might be in your PACS viewer. It might be in a research tool your radiology department installed. It might be in a third-party integration that converts or routes DICOM studies. The library has over 100,000 downloads and ships as a dependency in tools you've never audited.

That's what makes this vulnerability interesting to an attacker. You don't need to know exactly which systems use GDCM. You just need to send malformed DICOM files into the imaging pipeline and see what falls over.

The Bug

CWE-401: Missing Release of Memory after Effective Lifetime. When GDCM encounters a DICOM file with non-standard VR (Value Representation) types in the file meta information, it allocates memory to process those fields but never releases it. The memory just accumulates.

The attack vector is network-based. No authentication required. No user interaction needed. The CVSS v4 vector tells the story: AV:N/AC:L/AT:N/PR:N/UI:N. Translation: anyone on the network can trigger this with zero complexity and zero privileges.

In a hospital, DICOM traffic flows constantly. Studies come in from external imaging centers, referring physicians, mobile units, teleradiology partners. Every one of those connections is a potential delivery mechanism for a malformed file. And DICOM networks in most hospitals are not exactly locked down - they were designed for interoperability, not for adversarial conditions.

This Isn't GDCM's First Problem

If you're thinking "it's just a memory leak, how bad can it be?" - consider the pattern. In December 2025, GDCM caught CVE-2025-11266, a moderate-severity out-of-bounds write. Go further back and you find CVE-2015-8396 - a critical integer overflow in ImageRegionReader::ReadIntoBuffer - and CVE-2015-8397, a high-severity bug in the JPEG-LS codec.

This library has a history. And history, in my experience, is the best predictor of future vulnerabilities. An attacker looking at GDCM sees a codebase that has repeatedly failed to handle malformed input safely. That's not a library you trust with unauthenticated network-facing parsing in a clinical environment.

What Makes Healthcare Uniquely Exposed

Here's the thing most security teams outside healthcare don't understand: DICOM isn't optional. It's the protocol. Every CT scanner, every MRI machine, every ultrasound, every digital X-ray system speaks DICOM. The entire radiology workflow - from image acquisition to archival to diagnostic reading - depends on DICOM files being parsed correctly and quickly.

When a DICOM parser crashes or starts leaking memory, you don't just lose a service. You lose clinical capability. Studies can't be retrieved. Radiologists can't read images. Physicians can't make diagnostic decisions. In an emergency department, that delay can be the difference between catching a stroke on CT and missing the treatment window.

And here's what an attacker knows: denial of service against a hospital's imaging pipeline creates immediate pressure to pay, to call, to do whatever it takes to restore service. It's the same leverage that makes ransomware so effective in healthcare, but you can achieve it with a much simpler attack.

What to Do Right Now

First, figure out if you're exposed. Audit your imaging stack for GDCM. Check your PACS, your viewers, your routing tools, your research applications. GDCM ships as a library dependency - it won't show up in a simple software inventory. You need to check the dependency trees. The latest GDCM release is 3.0.24 from March 10, 2026, but as of now there's no confirmed patched version for CVE-2026-3650.

Second, segment your DICOM network traffic. If you haven't already isolated your imaging network from your general clinical network, this is another reason to move that up the priority list. DICOM traffic should not be flowing over the same network segments as your email and web browsing.

Third, monitor for anomalies. A memory leak from malformed DICOM files will show up as gradually increasing memory consumption on the affected system. If you're watching system metrics on your PACS and imaging servers - and you should be - set alerts for memory usage trends that don't follow normal study volume patterns.

This is exactly the kind of vulnerability that SecUnit's agents are built to catch. Our offensive validation agent would identify exposed DICOM endpoints and test how they handle malformed input before an attacker does. Our investigation agent would flag the abnormal memory consumption pattern in real time, correlate it with incoming DICOM traffic, and trace it back to the source. And our remediation agent would isolate the affected system and block the malformed traffic without taking the entire imaging pipeline offline.

The CVE is public. The CISA advisory is out. The patch status is unclear. If you have GDCM anywhere in your imaging stack, assume you're vulnerable until proven otherwise. Talk to us before someone tests your DICOM parsing for you.