# Is ITK vulnerable to gdcm CVE-2026-3650 memory consumption issue?
**URL:** https://discourse.itk.org/t/is-itk-vulnerable-to-gdcm-cve-2026-3650-memory-consumption-issue/7748
**Category:** Uncategorized
**Created:** [April 12, 2026, 11:18am UTC](https://discourse.itk.org/t/is-itk-vulnerable-to-gdcm-cve-2026-3650-memory-consumption-issue/7748 "2026-04-12T11:18:32Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@dclunie](https://discourse.itk.org/u/dclunie)
#### Post date: [April 12, 2026, 11:18am UTC](https://discourse.itk.org/t/is-itk-vulnerable-to-gdcm-cve-2026-3650-memory-consumption-issue/7748/1 "2026-04-12T11:18:32Z")
[https://www.cve.org/CVERecord?id=CVE-2026-3650](https://www.cve.org/CVERecord?id=CVE-2026-3650)
> **[Grassroots DICOM (GDCM) | CISA](https://www.cisa.gov/news-events/ics-medical-advisories/icsma-26-083-01)**
> **[CISA Flags Critical Flaw in Grassroots DICOM Imaging Library](https://www.govinfosecurity.com/cisa-flags-critical-flaw-in-grassroots-dicom-imaging-library-a-31246)**
>
> The Cybersecurity Infrastructure and Security Agency is warning of a high severity in Grassroots DICOM, an open-source library commonly used for medical imaging
---
### Author:  [@lassoan](https://discourse.itk.org/u/lassoan)
#### Post date: [April 13, 2026, 12:17am UTC](https://discourse.itk.org/t/is-itk-vulnerable-to-gdcm-cve-2026-3650-memory-consumption-issue/7748/2 "2026-04-13T00:17:01Z")
Bugs in file parsing deserves special attention, but the article is quite sensationalist. Many other similar problems (algorithms crashing, hanging, leaking memory if receiving incorrect or unusual input) are getting fixed in medical image computing libraries without being ever reported to vulnerability databases - probably because in this field it is just not common practice to use these tools.
That said, GDCM has many [open issues](https://sourceforge.net/p/gdcm/bugs/) (several of them referring to vulnerability databases), which should be fixed. I hope medical device companies that use GDCM take note and help out @mathieu.malaterre.
---
### Author:  [@blowekamp](https://discourse.itk.org/u/blowekamp)
#### Post date: [April 13, 2026, 1:02pm UTC](https://discourse.itk.org/t/is-itk-vulnerable-to-gdcm-cve-2026-3650-memory-consumption-issue/7748/3 "2026-04-13T13:02:21Z")
> [@lassoan](#):
>
> Bugs in file parsing deserves special attention, but the article is quite sensationalist.
Yes, I would expect (hope?) that critical medical systems are not importing DICOM files of unknown origin.
For this particular issue it does not appear that a “public” issue was created. Perhaps only e-mail was sent to the project developer where not response was received. I am not sure creating an article and issue like this is the best way for security individuals to interact with open source communities to get issues addressed.
> [@lassoan](#):
>
> I hope medical device companies that use GDCM take note and help out @mathieu.malaterre.
Agreed, I think GDCM is in need of more resources and effort.
---
### Author:  [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)
#### Post date: [April 15, 2026, 8:43pm UTC](https://discourse.itk.org/t/is-itk-vulnerable-to-gdcm-cve-2026-3650-memory-consumption-issue/7748/4 "2026-04-15T20:43:12Z")
Upstream patch here:
>
>
> \## Summary
>
> Fixes CVE-2026-3650, a denial-of-service vulnerability where a craft…ed DICOM file can trigger excessive memory allocation by declaring a Value Length far exceeding the actual stream data.
>
> \## Problem
>
> When parsing DICOM files, the Value Length (VL) field is read as a raw 32-bit unsigned integer and passed directly to \`ByteValue::SetLength()\`, which calls \`std::vector::resize()\`. A malicious file can set VL up to ~4 GB, causing a massive memory allocation \*\*before\*\* any data is read from the stream. This enables denial-of-service via memory exhaustion.
>
> Four code paths were unprotected:
> \- \`ExplicitDataElement::ReadValue()\` — explicit VR data elements
> \- \`ImplicitDataElement::ReadValue()\` — implicit VR data elements
> \- \`Fragment::ReadValue()\` — encapsulated pixel data fragments
> \- \`Fragment::ReadBacktrack()\` — fragment error-recovery path
>
> Additionally, \`SequenceOfFragments::ReadValue()\` had three out-of-bounds array accesses where \`bv-\>GetLength() - N\` was used without minimum length guards — two via \`gdcmAssertAlwaysMacro\` (active in release builds).
>
> \## Changes
>
> \### Stream-size validation (4 sites)
> Before allocating a \`ByteValue\`, the code now compares the declared VL against remaining bytes in the stream via \`tellg()\`/\`seekg()\`. If VL exceeds available data, an \`Exception\` is thrown. Non-seekable streams skip the check gracefully. Stream state (\`end\` position validity and \`is.good()\`) is verified after seeking.
>
> \*\*Files:\*\*
> \- \`Source/DataStructureAndEncodingDefinition/gdcmExplicitDataElement.txx\`
> \- \`Source/DataStructureAndEncodingDefinition/gdcmImplicitDataElement.txx\`
> \- \`Source/DataStructureAndEncodingDefinition/gdcmFragment.h\`
>
> \### Out-of-bounds access fixes (3 sites)
> Added minimum-length guards before array accesses in broken-implementation recovery paths:
> \- Line 170: \`bv-\>GetLength() \>= 1\` (debug assert)
> \- Line 191: \`bv-\>GetLength() \>= 1\` (release assert)
> \- Line 215: \`bv-\>GetLength() \>= 2\` (release assert)
>
> \*\*File:\*\* \`Source/DataStructureAndEncodingDefinition/gdcmSequenceOfFragments.h\`
>
> \### Test
> Added \`TestCVE20263650.cxx\` covering all three vulnerability vectors (Explicit VR, Implicit VR, Fragment) with a 1 GB VL on a ~20-byte stream. The test verifies \`gdcm::Exception\` is thrown and specifically fails on \`std::bad\_alloc\` (which would indicate the allocation was attempted).
>
> \## Test plan
> \- \[x\] \`TestCVE20263650\` passes — all three sub-tests reject oversized VL
> \- \[x\] All 42 existing DSED tests pass with no regressions
> \- \[x\] CodeRabbit review — all findings addressed
>
> \## References
> \- \[ITK Discourse: Is ITK vulnerable to GDCM CVE-2026-3650?\](https://discourse.itk.org/t/is-itk-vulnerable-to-gdcm-cve-2026-3650-memory-consumption-issue/7748/3)
We will integrate into ITK 5.4.6.
---
### Author:  [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)
#### Post date: [April 16, 2026, 8:13pm UTC](https://discourse.itk.org/t/is-itk-vulnerable-to-gdcm-cve-2026-3650-memory-consumption-issue/7748/5 "2026-04-16T20:13:34Z")
ITK patch:
>
>
> Backport of GDCM PR https://github.com/malaterre/GDCM/pull/214 (commit 23bca9286…a7efe8be97d67015aa280138fa8d4b1).
>
> A crafted DICOM file could specify an arbitrarily large Value Length field (up to ~4 GB), causing ByteValue::SetLength() to attempt a massive memory allocation before any stream data is read. This enables denial-of-service via memory exhaustion.
>
> Add stream-size validation in ExplicitDataElement::ReadValue(), ImplicitDataElement::ReadValue(), Fragment::ReadValue(), and Fragment::ReadBacktrack(). Before allocating a ByteValue, the code now compares the declared VL against the remaining bytes in the stream via tellg()/seekg(). Non-seekable streams skip the check gracefully.
>
> Also fix out-of-bounds array accesses in SequenceOfFragments where bv-\>GetLength() - N was used without verifying minimum length, affecting lines that use gdcmAssertAlwaysMacro (active in release).
>
> The TestCVE20263650 test added upstream is not included, as ITK's GDCM subtree does not vendor the Testing/ directory.