Description

Uncontrolled recursion in DcmSequenceOfItems::read() and DcmItem::read() in the dcmdata library of OFFIS DCMTK 3.7.0 allows a remote, unauthenticated attacker to cause a denial of service (stack exhaustion and process crash) via a DICOM dataset containing deeply nested sequences (SQ elements). The dataset can be sent in a C-STORE request to storescp, dcmrecv, dcmqrscp, or any other DICOM service built on DCMTK, because the received dataset is parsed before any authentication takes place. Local tools such as dcmdump also crash when opening such a file. The issue is fixed in commit 885ff0f10372bd589b5f44cea974f28a3964cb0f, which adds a configurable sequence nesting depth limit (default 64).

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-10-08T13:17:17.027Z",
  "pubdate": "2026-10-08T13:17:17.027Z",
  "executiveSummary": "DCMTK 3.7.0 is susceptible to a stack exhaustion vulnerability originating from uncontrolled recursion within the dcmdata library's sequence parsing logic. Specifically, the DcmSequenceOfItems::read() and DcmItem::read() functions fail to enforce constraints on the depth of nested DICOM sequence (SQ) elements during dataset deserialization.\nA remote, unauthenticated attacker can trigger this vulnerability by submitting a maliciously crafted DICOM dataset containing deeply nested sequences. Because parsing occurs prior to authentication in DICOM services such as storescp, dcmrecv, and dcmqrscp, the attack vector is highly accessible. Successful exploitation leads to uncontrolled recursive function calls, resulting in stack overflow, process termination, and a Denial of Service (DoS).\nThis vulnerability poses a significant risk to clinical imaging infrastructure where availability is critical. Local processing tools like dcmdump are equally susceptible, allowing an attacker to trigger a crash simply by inducing a victim to open a specially crafted DICOM file. The impact is limited to service availability, with no evidence of code execution, though the ease of triggering the crash makes it a high-utility target for service disruption.",
  "technicalDetails": "The vulnerability resides in the recursive descent parsing mechanism implemented in the dcmdata library of OFFIS DCMTK 3.7.0. The DcmSequenceOfItems::read() and DcmItem::read() functions are responsible for parsing nested DICOM structures. The logic does not implement a depth counter or a maximum nesting limit during the traversal of DICOM sequences (Value Representation SQ).\nWhen a service such as storescp receives a DICOM association, it invokes these functions to parse the incoming dataset. An attacker can construct a DICOM object where SQ elements contain further SQ elements, repeating this structure to a depth that exceeds the allocated stack frame for the thread. As the parser recursively descends into these nested containers, each level consumes additional stack memory.\nThe attack flow follows a predictable pattern: 1) The attacker transmits a DICOM object via a C-STORE request or local file processing; 2) The dcmdata parser enters the recursive loop, continuously calling read() on child elements; 3) The memory exhaustion triggers a stack overflow exception; 4) The operating system terminates the process due to a segmentation fault or stack guard violation. Because the parser does not authenticate the sender or validate the schema structure prior to deserialization, the input is processed blindly.\nThe vulnerable code fails to validate the nesting depth, allowing an arbitrary sequence depth to be processed until the stack limit is reached. The lack of an iterative stack management approach or a depth-limiting counter makes the system fragile against maliciously nested datasets. The fix, introduced in commit 885ff0f10372bd589b5f44cea974f28a3964cb0f, introduces a configurable maximum nesting depth—defaulting to 64—to prevent the recursion from exhausting system resources. This prevents the parser from entering the recursive call chain once the safety threshold is breached, effectively mitigating the stack exhaustion path."
}