CVE-2026-35505: Memory Leak Denial of Service Vulnerability

CVE-2026-35505 Overview

CVE-2026-35505 is a memory leak vulnerability [CWE-401] affecting the DICOM Toolkit (DCMTK), an open source implementation of the DICOM standard used widely in medical imaging systems. An unauthenticated remote attacker can repeatedly send crafted connection requests that cause the service to leak memory over time. In single-process deployments, memory consumption grows until the operating system terminates the service, and the listening port stops responding until a manual restart occurs. CISA published medical device advisory ICSMA-26-181-01 covering this issue, reflecting its relevance to healthcare environments where DCMTK is embedded in imaging workflows.

Critical Impact
Unauthenticated network attackers can crash DICOM services and halt medical imaging traffic without any credentials or user interaction.

Affected Products

DCMTK (DICOM Toolkit) — see the GitHub DCMTK Release for fixed versions
Medical imaging products embedding DCMTK for DICOM network services
Single-process DCMTK deployments listening on DICOM ports

Discovery Timeline

2026-06-30 - CVE-2026-35505 published to NVD
2026-07-01 - Last updated in NVD database

Technical Details for CVE-2026-35505

Vulnerability Analysis

The flaw is a missing release of allocated memory after its effective lifetime [CWE-401]. When DCMTK processes an incoming DICOM association or connection request, allocated buffers and state structures are not freed under certain crafted inputs. Each malicious connection attempt increases the resident memory footprint of the service. Because the attack requires no authentication and no user interaction, an adversary with network reach to the DICOM port can automate the request loop and exhaust available memory.

In multi-process or forked deployments, the impact is bounded by the lifetime of each worker. In single-process deployments the leak accumulates in one address space until the kernel out-of-memory killer terminates the service, at which point the DICOM port becomes unreachable until an operator restarts the process.

Root Cause

The root cause is an incomplete cleanup path in the connection-handling logic of DCMTK. Memory allocated during association negotiation is not released on specific error or protocol states, leaving orphaned allocations for the process lifetime. The condition is deterministic and reachable from unauthenticated network input, which is why the availability impact is rated high.

Attack Vector

The attack vector is network-based. An attacker sends a stream of crafted DICOM connection requests to the target port, typically TCP 104 or a locally configured DICOM listener. No credentials, no privileges, and no user interaction are required. Refer to the CISA Medical Advisory ICSMA-26-181-01 and the CISA CSAF White Paper for structured advisory data.

No verified public exploit code is available at the time of writing. The vulnerability mechanism is described in prose because no sanitized proof-of-concept has been released by the vendor or a coordinated researcher.

Detection Methods for CVE-2026-35505

Indicators of Compromise

Sustained growth of resident set size (RSS) for DCMTK processes such as storescp, dcmqrscp, or embedded DICOM listeners without corresponding legitimate workload.
Repeated short-lived TCP connections to DICOM ports (commonly 104, 11112, or vendor-specific) from a single source or small set of sources.
Unexpected out-of-memory kills of DICOM services recorded in dmesg or systemd journal entries referencing oom-killer.
DICOM port becoming unresponsive followed by manual restart events in service management logs.

Detection Strategies

Baseline normal memory consumption of DICOM services and alert on sustained upward drift over hours.
Correlate connection-rate spikes to DICOM ports with concurrent RSS increase on the hosting workload.
Monitor kernel OOM events and service restart counters for hosts running DCMTK-based applications.

Monitoring Recommendations

Enable process-level memory telemetry on medical imaging servers and forward it to a central analytics platform.
Capture NetFlow or connection metadata for DICOM ports and flag high-frequency connection attempts from non-clinical sources.
Alert on repeated crash-restart cycles of DICOM listener processes, which indicate active exploitation of the leak.

How to Mitigate CVE-2026-35505

Immediate Actions Required

Update DCMTK to the fixed release listed at the GitHub DCMTK Release page as soon as the vendor of the embedding medical device authorizes it.
Restrict network reachability of DICOM ports to known imaging modalities, PACS, and workstations using firewall or segmentation rules.
Contact medical device manufacturers to confirm which shipping product versions embed the vulnerable DCMTK code.

Patch Information

The DCMTK maintainers publish fixed builds through their GitHub release channel. Operators of medical imaging systems should coordinate patch deployment with device manufacturers because DCMTK is frequently statically linked into vendor products and cannot be upgraded independently. Refer to CISA Medical Advisory ICSMA-26-181-01 for vendor-specific remediation status.

Workarounds

Place DICOM listeners behind a network access control list that only permits traffic from authorized peer AE titles and IP addresses.
Deploy a DICOM-aware proxy or gateway that terminates untrusted connections and rate-limits association requests.
Configure automated service supervision (systemd, container orchestrator) to restart DICOM listeners on failure while the underlying patch is being deployed.
Prefer multi-process or forked deployment modes where available, so that a leaked worker is reaped without impacting the parent listener.

bash

# Example: restrict DICOM port 104 to authorized modalities using nftables
nft add table inet dicom
nft add chain inet dicom input '{ type filter hook input priority 0; policy drop; }'
nft add rule inet dicom input ip saddr { 10.10.20.0/24, 10.10.21.0/24 } tcp dport 104 accept
nft add rule inet dicom input tcp dport 104 drop