GCVE-1988-2026-0475

Vulnerability from gna-1988 – Published: 2026-11-02 07:30 – Updated: 2026-11-02 07:30
VLAI
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
VULNARCHIVE GNA GNA-1988
GNA scorecard E 38/100 over 556 records in the last 180 days details
References
Impacted products
Vendor Product Version CPE status
unknown dcm4che Affected: unknown
guessed Create a notification for this product.
Credits
Matthias Deeg via Fulldisclosure
To clipboard 

{
  "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"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON
How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

Loading timeline…




    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.