High priorityDisclosed

Advisory · CVE-2026-97059

DCMTK heap over-read can leak memory or crash medical imaging software

DCMTK through 3.7.0 copies pixel data frames without validating the PixelData buffer length against the declared NumberOfFrames, so a crafted DICOM instance triggers heap over-reads that crash the application or leak adjacent heap memory.

Advisory published September 24, 2026Independent summary
Vendor
OFFIS
Product
DCMTK
Identifier / CWE
CVE-2026-97059
CWE-125
Action timing
Immediate
ELI5

Explain it like I’m five

DCMTK reads medical image files and trusts the file's own claim about how many picture frames it contains. A doctored file lies about the frame count, and DCMTK reads past the end of its memory buffer, spilling nearby memory contents or crashing outright.

SIMPLIFIED_ATTACK_PATH04 STEPS
  1. 01Crafted DICOM instance

    An attacker builds a DICOM file whose NumberOfFrames value declares more frames than the PixelData buffer holds.

  2. 02ConcatenationLoader

    DCMTK's ConcatenationLoader copies pixel data frames without validating the buffer length against the declared frame count.

  3. 03Heap over-read

    The copy reads past the end of the heap buffer into adjacent memory.

  4. 04Crash or leak

    The application crashes, or the over-read memory content is exposed to the attacker.

What happened

DCMTK through 3.7.0 contains a heap over-read vulnerability in ConcatenationLoader, disclosed on September 24, 2026. When copying pixel data frames, the code does not validate the PixelData buffer length against the declared NumberOfFrames value. A crafted DICOM instance declaring more frames than the buffer contains triggers heap over-reads that crash the application or leak adjacent heap memory. The issue is rated high at CVSS 8.8.

DCMTK is the reference open-source DICOM toolkit, embedded in picture archiving and communication systems, viewers, and imaging pipelines across healthcare. Attackers can deliver the malicious instance through any channel the software ingests: DICOM network transfers, imported files, or shared media.

What to do

  1. Inventory software and services built on DCMTK, including PACS components, DICOM viewers, and imaging integration engines.
  2. Treat DCMTK through 3.7.0 as affected and upgrade to a release containing the upstream fix.
  3. Restrict which sources can submit DICOM data to unpatched systems where possible.
  4. Review logs for crashes or anomalies around DICOM ingestion following the disclosure.
  5. Assess whether any process that crashed could have exposed heap contents to an external party.

Management note

This is a classic malformed-input bug in a widely embedded library, in a sector where patching cycles are slow and downtime is expensive. The fix is an upgrade, but the real work is finding every system that silently depends on DCMTK and confirming what ingested data they processed.