CVE-2026-56445: DICOM path traversal enables

CISO Take

A critical flaw in qrscp's DICOM C-STORE handler takes an attacker-controlled field from an inbound DICOM dataset and feeds it straight into os.path.join() without sanitizing path traversal sequences, letting an unauthenticated remote attacker write files to arbitrary locations on the receiving server. This scores CVSS 9.1 with network access, low complexity, and zero privileges or user interaction required — the kind of profile that should worry anyone running a DICOM ingestion endpoint for medical imaging or research data pipelines. The mitigating factors are real: EPSS sits at 0.43% (top 65th percentile, not the tail), it isn't in CISA KEV, there's no public exploit or Nuclei template yet, and CISA's own SSVC decision is TRACK — the lowest urgency tier, meaning no evidence of active exploitation. That said, this is a CISA ICS medical advisory (ICSMA-26-176-01), so treat any Internet- or lab-network-exposed qrscp/pynetdicom-based C-STORE listener as high priority to patch or firewall off now, and monitor for file writes landing outside the configured storage directory as a detection signal while a fix is applied.

Sources: NVD EPSS CISA ATLAS GitHub

What is the risk?

Technically severe (CVSS 9.1, network-exploitable, no auth or user interaction) but currently low-urgency from a threat-activity standpoint: EPSS is low (0.43%), not in CISA KEV, no public PoC or scanner template exists, and CISA's SSVC decision is TRACK (lowest priority tier). The combination of trivial exploitability and unauthenticated network access means this should be patched proactively rather than reactively — SSVC ratings can change quickly once a PoC surfaces for a straightforward path traversal like this one.

How does the attack unfold?

Initial Access

Attacker sends a crafted DICOM C-STORE request to the network-exposed qrscp listener with no authentication required.

AML.T0049

Malicious Field Crafting

Attacker embeds a path traversal sequence in a DICOM instance field (e.g. SOP Instance UID) that the handler trusts as a filename component.

Path Traversal Write

The unsanitized field is passed into os.path.join(), causing the server to write the DICOM payload outside the intended storage directory.

AML.T0010.002

Impact / Persistence

The attacker-controlled file overwrites sensitive system files or plants executable content (e.g. a web shell or cron entry), enabling further compromise or denial of service.

Initial Access

Attacker sends a crafted DICOM C-STORE request to the network-exposed qrscp listener with no authentication required.

AML.T0049

Malicious Field Crafting

Attacker embeds a path traversal sequence in a DICOM instance field (e.g. SOP Instance UID) that the handler trusts as a filename component.

Path Traversal Write

The unsanitized field is passed into os.path.join(), causing the server to write the DICOM payload outside the intended storage directory.

AML.T0010.002

Impact / Persistence

The attacker-controlled file overwrites sensitive system files or plants executable content (e.g. a web shell or cron entry), enabling further compromise or denial of service.

How severe is it?

CVSS 3.1

9.1 / 10

EPSS

0.4%

chance of exploitation in 30 days

Higher than 36% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AV Network

AC Low

PR None

UI None

S Unchanged

C None

I High

A High

What should I do?

1 step

Patch qrscp/pynetdicom to a version that sanitizes DICOM element values (notably SOP Instance UID) before using them in filesystem path construction — never use os.path.join() with unsanitized external input; validate with os.path.basename() and reject values containing '..' or path separators. Until patched, restrict network exposure of the C-STORE listener to trusted VLANs/VPNs only, run the service under a low-privilege account with a chroot or restricted write directory, and monitor for file creation/modification events outside the intended DICOM storage path (e.g. via auditd or filesystem integrity monitoring). Validate incoming DICOM datasets against expected schema/whitelisted characters before storage.

What does CISA's SSVC say?

Decision Track*

Exploitation none

Automatable Yes

Technical Impact total

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Code Execution DoS Training Data AML.T0010.002 - Data AML.T0049 - Exploit Public-Facing Application

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.10 - Data for AI systems

NIST AI RMF

MEASURE 2.7 - AI system security and resilience evaluation

Frequently Asked Questions

What is CVE-2026-56445?

A critical flaw in qrscp's DICOM C-STORE handler takes an attacker-controlled field from an inbound DICOM dataset and feeds it straight into os.path.join() without sanitizing path traversal sequences, letting an unauthenticated remote attacker write files to arbitrary locations on the receiving server. This scores CVSS 9.1 with network access, low complexity, and zero privileges or user interaction required — the kind of profile that should worry anyone running a DICOM ingestion endpoint for medical imaging or research data pipelines. The mitigating factors are real: EPSS sits at 0.43% (top 65th percentile, not the tail), it isn't in CISA KEV, there's no public exploit or Nuclei template yet, and CISA's own SSVC decision is TRACK — the lowest urgency tier, meaning no evidence of active exploitation. That said, this is a CISA ICS medical advisory (ICSMA-26-176-01), so treat any Internet- or lab-network-exposed qrscp/pynetdicom-based C-STORE listener as high priority to patch or firewall off now, and monitor for file writes landing outside the configured storage directory as a detection signal while a fix is applied.

Is CVE-2026-56445 actively exploited?

No confirmed active exploitation of CVE-2026-56445 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-56445?

Patch qrscp/pynetdicom to a version that sanitizes DICOM element values (notably SOP Instance UID) before using them in filesystem path construction — never use os.path.join() with unsanitized external input; validate with os.path.basename() and reject values containing '..' or path separators. Until patched, restrict network exposure of the C-STORE listener to trusted VLANs/VPNs only, run the service under a low-privilege account with a chroot or restricted write directory, and monitor for file creation/modification events outside the intended DICOM storage path (e.g. via auditd or filesystem integrity monitoring). Validate incoming DICOM datasets against expected schema/whitelisted characters before storage.

What systems are affected by CVE-2026-56445?

This vulnerability affects the following AI/ML architecture patterns: training data pipelines, data ingestion pipelines.

What is the CVSS score for CVE-2026-56445?

CVE-2026-56445 has a CVSS v3.1 base score of 9.1 (CRITICAL). The EPSS exploitation probability is 0.43%.

What is the AI security impact?

Affected AI Architectures

training data pipelinesdata ingestion pipelines

MITRE ATLAS Techniques

AML.T0010.002 Data

AML.T0049 Exploit Public-Facing Application

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.10

NIST AI RMF: MEASURE 2.7

What are the technical details?

Original Advisory

The qrscp application's C-STORE handler uses a specific instance from attacker-supplied DICOM datasets directly in os.path.join() without sanitization, allowing file writes to arbitrary paths.

Exploitation Scenario

An attacker with network reachability to the exposed DICOM C-STORE port crafts a DICOM dataset where the SOP Instance UID (or another server-trusted field) contains a path traversal sequence such as '../../../etc/cron.d/malicious' or a web-root path. The qrscp handler, expecting only an instance identifier, passes this value directly into os.path.join() to build the destination file path and writes the DICOM payload there without validation. Because the process runs with write access to sensitive directories, this can overwrite cron jobs, SSH authorized_keys, or drop a web shell into a served directory — turning a healthcare imaging intake service into a foothold for full host compromise, with no authentication or user interaction needed.

Weaknesses (CWE)

CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') Primary CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

CWE-22 — Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'): The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.

[Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylis
[Architecture and Design] For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Source: MITRE CWE corpus.