CVE-2026-44034 in DCMTK
Summary
by MITRE • 10/08/2026
A heap-based out-of-bounds read in DcmRLECodecDecoder::decodeFrame() in dcmdata/libsrc/dcrleccd.cc of OFFIS DCMTK 3.7.0 allows an attacker to read up to 63 bytes of adjacent heap memory, or cause a crash, via a crafted RLE Lossless DICOM file whose pixel data fragment is shorter than the 64-byte RLE header. The function copies 64 bytes without checking the fragment length, a check that the sibling function decode() already performs. Applications that decode RLE images frame by frame (for example, through DcmPixelData::getUncompressedFrame()) are affected. The dcmdrle command-line tool uses decode() and is not affected. The issue is fixed in commit 45469f3c30037e9c7159290e4bb74cd7b3b9ef1d.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/08/2026
The vulnerability identified in OFFIS DCMTK version 3.7.0 represents a critical heap-based out-of-bounds read within the RLE Lossless codec implementation, specifically located in the decodeFrame function of the dcrleccd.cc source file. This flaw arises from an insufficient boundary check during the processing of pixel data fragments in DICOM files that utilize Run Length Encoding compression. When an application attempts to decompress a frame using this specific decoder routine, it assumes that the incoming data fragment contains at least sixty-four bytes of header information required for proper decoding initialization. However, the implementation fails to validate whether the actual length of the provided pixel data fragment meets this minimum threshold before attempting to copy or process these initial bytes. This lack of validation allows an attacker who can supply a maliciously crafted DICOM file with a truncated RLE header to trigger memory access violations beyond the allocated buffer boundaries.
From a technical perspective, the core issue is a classic off-by-one or insufficient bounds checking error where the decoder proceeds to read up to sixty-three bytes from adjacent heap memory if the fragment length is less than sixty-four bytes. This behavior contrasts sharply with the sibling decode function within the same library, which correctly implements length verification before processing data. The inconsistency between these two functions highlights a gap in defensive coding practices for frame-by-frame decoding operations. Applications that rely on DcmPixelData::getUncompressedFrame() to process images incrementally are directly susceptible to this flaw because they invoke the vulnerable decodeFrame routine rather than the safer full-image decode method. Consequently, tools like dcmdrle which utilize the protected decode function remain unaffected by this specific vector of attack.
The operational impact of this vulnerability is significant for any system relying on DCMTK to parse or display medical imaging data containing RLE-compressed pixel sets. An attacker can exploit this condition to perform an arbitrary heap read, potentially leaking sensitive information stored in adjacent memory regions such as cryptographic keys, session tokens, or other application-specific secrets. Furthermore, if the accessed memory addresses are unmapped or protected by operating system security mechanisms, the exploitation will result in a denial of service through application crash rather than data exfiltration. This dual nature of impact classifies the vulnerability under CWE-125 Out-of-bounds Read and aligns with ATT&CK techniques related to Data from Local System Memory for reconnaissance purposes or causing instability for disruption.
Mitigation strategies primarily involve upgrading to a patched version of DCMTK where this logic error has been resolved, specifically referencing commit 45469f3c30037e9c7159290e4bb74cd7b3b9ef1d. For organizations unable to immediately patch their infrastructure, implementing input validation at the application layer is recommended as a temporary countermeasure. This includes verifying that incoming DICOM files have valid and complete RLE headers before passing them to the decoder routines. Additionally, developers should ensure consistent use of safe decoding functions across all code paths involving pixel data extraction to prevent similar discrepancies from arising in other parts of the media processing pipeline. Regular security audits focusing on buffer handling in image parsing libraries are essential to maintain resilience against such memory corruption vulnerabilities.