DCMTK EUVD-2026-85885

Exploitation requires that the target application uses DCMTK's dcmfg ConcatenationLoader to load a multi-frame DICOM concatenation, and that the attacker can supply a DICOM instance whose NumberOfFrames (combined with Rows/Columns/BitsAllocated geometry) declares more pixel data than the PixelData element actually contains. The realistic limiting factor is the ingestion path: fully remote-unauthenticated exploitation applies only where DCMTK processes untrusted instances automatically (e.g. a DICOM network storage/receiver service); for offline viewers or command-line tools, an operator typically must open the malicious file, effectively making it local with user interaction. Only versions through 3.7.0 are affected, and the primary reliable impact is a crash (DoS), with heap-memory disclosure being conditional on how leaked frame bytes are subsequently exposed.

The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:H) rates this 8.8 (High), driven almost entirely by the availability impact (VA:H, application crash) with only low confidentiality (VC:L, adjacent-heap leak) and no integrity impact - consistent with a CWE-125 heap over-read confirmed by the patch diff, which adds explicit buffer-length validation before the frame-by-frame copy. No EPSS score, KEV listing, or SSVC decision data is provided, and there is no public exploit code identified - only a VulnCheck advisory describing the flaw. Real-world priority is moderate-to-serious in DICOM-processing/PACS environments where DCMTK ingests attacker-influenced instances: the primary realistic outcome is denial of service (crash), with heap-memory disclosure being harder to weaponize reliably. Note a caveat on the attack vector: DCMTK is a library, and whether AV:N truly applies depends on deployment - a DICOM network service (e.g. storescp-style receiver) processing untrusted instances justifies AV:N/PR:N/UI:N, but a purely file-based/offline tool would effectively be local (AV:L) and often require a user to open the file (UI:R). Verify the ingestion path in your specific product before treating this as fully remote-unauthenticated.

An attacker crafts a malicious DICOM instance in which NumberOfFrames declares more frames than the PixelData element actually contains, then delivers it to a system that loads concatenations via DCMTK (e.g. a PACS/DICOM receiver or viewer). When ConcatenationLoader copies the announced frames, it reads past the end of the heap buffer, crashing the service (denial of service) or copying adjacent heap memory into output frames (information leak). No public exploit code is identified, but the malicious-file construction is straightforward and a validating test case is included in the vendor patch.