CVE-2026-97059 in DCMTK
Summary
by MITRE • 09/24/2026
DCMTK through 3.7.0 contains a heap over-read vulnerability in ConcatenationLoader that copies pixel data frames without validating the PixelData buffer length against the declared NumberOfFrames. Attackers can craft malicious DICOM instances declaring more frames than the buffer contains to trigger heap over-reads that crash the application or leak adjacent heap memory.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/24/2026
The vulnerability identified in DCMTK versions through 3.7.0 represents a critical failure in input validation within the ConcatenationLoader component, specifically affecting how pixel data frames are processed from DICOM medical imaging files. This flaw stems from an insufficient boundary check where the software fails to verify that the actual length of the PixelData buffer corresponds accurately with the NumberOfFrames attribute declared by the file creator. In a properly secured implementation, any discrepancy between the number of frames specified in the metadata and the available data in the buffer should trigger an immediate error or truncation to prevent out-of-bounds access. However, due to this oversight, the application proceeds to copy pixel data based solely on the untrusted NumberOfFrames value without confirming that sufficient memory is allocated for those specific frames. This architectural weakness allows attackers who can supply maliciously crafted DICOM instances to exploit the logic error by declaring a higher number of frames than what actually exists in the buffer payload.
From an operational perspective, this heap over-read vulnerability poses significant risks to both system stability and data confidentiality. When the application attempts to read beyond the allocated bounds of the PixelData buffer, it accesses adjacent memory regions that may contain sensitive information or control structures not intended for exposure. The immediate consequence is often a denial of service condition manifested as an application crash, which disrupts critical medical imaging workflows and can lead to downtime in healthcare environments relying on DCMTK for image processing. More severely, the ability to read arbitrary heap memory opens avenues for information disclosure attacks where attackers may extract secrets such as cryptographic keys, user credentials, or other proprietary data stored in adjacent memory locations. This type of vulnerability is particularly dangerous because it does not require code execution privileges initially but can serve as a stepping stone for more complex exploitation chains involving remote code execution if combined with additional techniques like heap spraying or specific return-oriented programming strategies.
The technical classification of this flaw aligns closely with CWE-125, which describes out-of-bounds read vulnerabilities where software reads data past the end, or before the beginning, of the intended buffer. In the context of modern attack frameworks, this behavior maps to ATT&CK technique T1083, specifically related to file and directory discovery through memory inspection rather than direct filesystem access. The exploitation vector typically involves an attacker crafting a DICOM file with manipulated metadata fields that misrepresent the size or count of embedded image data. When such a file is processed by a vulnerable version of DCMTK, whether in a PACS server, viewer application, or preprocessing pipeline, the loader invokes unsafe memory operations that bypass standard safety checks. This highlights a broader issue in legacy medical imaging libraries where performance optimizations sometimes come at the cost of rigorous input sanitization, leaving systems exposed to malformed file attacks.
Mitigation strategies for this vulnerability must prioritize immediate patching and defensive coding practices. The primary remediation is to upgrade DCMTK to version 3.7.1 or later, where developers have implemented proper validation logic that cross-references the NumberOfFrames attribute against the actual buffer size before initiating data copying operations. For organizations unable to update immediately due to compatibility constraints, deploying a network-level intrusion detection system capable of inspecting DICOM traffic for anomalous metadata values can provide temporary protection by blocking requests with suspicious frame counts. Additionally, developers integrating DCMTK into custom applications should implement wrapper functions that validate input parameters before passing them to the library’s core processing routines. Enabling strict memory debugging tools during development and testing phases can also help identify similar boundary issues in other parts of the codebase. Regular security audits focusing on buffer management and heap allocation patterns are essential to prevent recurrence of such out-of-bounds access flaws in medical software ecosystems.