OFFIS DCMTK CVE-2026-44034

Exploitation requires the victim application to decode RLE Lossless DICOM pixel data via the frame-by-frame path - specifically DcmRLECodecDecoder::decodeFrame(), reached through APIs like DcmPixelData::getUncompressedFrame(). The malicious input must be an RLE Lossless DICOM file whose pixel-data fragment is shorter than the 64-byte RLE header. Key LIMITING factors: the attack is local and needs passive user interaction (a user or automated pipeline must open/process the attacker's file); applications using the sibling decode() path - including the bundled dcmdrle command-line tool - are NOT affected because decode() already performs the length check; and only DCMTK 3.7.0 integrations lacking the commit-45469f3c fix are vulnerable.

This is a genuinely low-to-moderate priority issue, not a high-urgency flaw. The vendor-provided CVSS 4.0 vector (AV:L/AC:L/PR:N/UI:P/VC:L/VI:N/VA:L) describes a local attack vector requiring passive user interaction (a victim application must process an attacker-supplied file), yielding only a low confidentiality impact (up to 63 bytes of adjacent heap) and low availability impact (a crash) - hence the 4.8 base score, which is accurate for the technical impact. There is no public exploit identified at time of analysis and no CISA KEV listing, so no active exploitation is indicated. No EPSS score or SSVC decision data was provided in the input, so exploitation probability and automatability cannot be quantified here. The attack vector is correctly LOCAL rather than network: exploitation hinges on getting a crafted DICOM file into an application that uses the frame-by-frame decode path, not on a remote service. The impact is self-consistent with the description (bounded 63-byte over-read plus potential crash), so there is no conflict between the vector and the narrative. Bottom line: a well-characterized memory-safety bug with a clear patch, worth remediating in medical-imaging software supply chains but not an emergency.

An attacker crafts a malicious RLE Lossless DICOM file whose pixel-data fragment is shorter than the mandatory 64-byte RLE header. A victim runs a medical-imaging application that decodes images frame by frame (e.g., via DcmPixelData::getUncompressedFrame()) and opens the file, causing the decoder to copy 64 bytes from an under-sized buffer. This leaks up to 63 bytes of adjacent heap memory into the decoded output or crashes the application; no public exploit code is identified at time of analysis.