CVE-2026-44036 in DCMTK
Summary
by MITRE • 10/08/2026
Uncontrolled mutual recursion between DcmXMLParseHelper::parseDataSet() and DcmXMLParseHelper::parseSequence() in the XML-to-DICOM converter (dcmdata/libdcxml/xml2dcm.cc) of OFFIS DCMTK 3.7.0 allows an attacker to cause a denial of service (stack exhaustion and process crash) via a crafted XML file with deeply nested sequence and item elements. The xml2dcm tool and any service that converts untrusted XML to DICOM with this code are affected. The issue is fixed in commit 87f256d73e30656a822bf7d76d1cf1d9bb693954.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/08/2026
The vulnerability identified involves an uncontrolled mutual recursion within the XML-to-DICOM conversion utility of OFFIS DCMTK version 3.7.0, specifically located in the DcmXMLParseHelper class methods parseDataSet and parseSequence found in xml2dcm.cc. This architectural flaw allows for a denial of service attack through stack exhaustion when processing maliciously crafted input files. The core technical issue stems from the recursive nature of parsing DICOM data structures that are represented as nested XML elements, where sequences contain items which themselves may contain further datasets and sequences without adequate depth limiting mechanisms in place during the initial conversion phase.
An attacker can exploit this weakness by constructing an XML file with deeply nested sequence and item elements. As the parser processes these layers of nesting, it invokes parseSequence for each level of a DICOM sequence element and subsequently calls parseDataSet when encountering items within those sequences. Because there is no explicit recursion depth limit or stack size check implemented in the affected code path, this mutual recursion continues until the system's call stack is completely exhausted. This results in a segmentation fault or process crash, effectively rendering the xml2dcm tool unavailable for legitimate operations and potentially disrupting any downstream services that rely on converting untrusted XML data into DICOM format using this specific library version.
From an industry standard perspective, this vulnerability aligns with CWE-675, which describes the use of algorithms with insufficiently bounded recursion depth leading to resource exhaustion. It also relates to CWE-400 regarding unconstrained resource consumption, as the attacker controls the input structure that directly dictates memory usage on the stack rather than heap space. In terms of attack patterns, this scenario is consistent with ATT&CK technique T1496, Resource Hijacking, specifically through denial of service via resource exhaustion. The lack of validation against structural complexity in untrusted inputs allows for a straightforward exploitation path that does not require code execution privileges on the target system, only access to feed data into the conversion process.
The operational impact is primarily focused on availability rather than confidentiality or integrity. Systems relying on OFFIS DCMTK 3.7.0 for medical imaging workflow automation may experience service interruptions if they accept XML inputs from untrusted sources without prior sanitization or structural validation. This includes hospital information systems, PACS integrations, and any custom applications that utilize the libdcxml library to transform external data formats into standard DICOM objects. The crash prevents further processing of valid requests as well, causing a complete service outage until the process is restarted or the vulnerability is patched.
Mitigation strategies involve upgrading to a version of OFFIS DCMTK where this issue has been resolved via commit 87f256d73e30656a822bf1d9bb693954, which implements safeguards against excessive recursion depth. In environments where immediate patching is not feasible, administrators should implement strict input validation at the network or application boundary to reject XML files with nesting levels exceeding a reasonable threshold for DICOM structures. Additionally, deploying web application firewalls or API gateways that can detect and block excessively deep hierarchical payloads before they reach the conversion service provides an effective defense-in-depth measure against this specific stack exhaustion vector.