CVE-2026-32711

What it actually does

pydicom 2.0.0-rc.1 through 3.0.1 fails to confine DICOMDIR ReferencedFileID resolution to the File-set root. The library only checks that the resolved path exists and then uses that unchecked path in FileSet copy(), write(), and remove()+write(use_existing=True) I/O. A crafted ReferencedFileID can therefore cause arbitrary file read and copy, and in some flows move or delete, of files outside the intended File-set. Impact is local confidentiality, integrity, and availability of files the process can access (CVSS 7.8, AV:L/UI:R).

Why it matters to the business

Healthcare and imaging workflows that ingest untrusted DICOM File-sets with pydicom can expose or alter patient studies and unrelated host files, disrupting clinical operations and creating privacy or integrity incidents. The issue is not in KEV, has no reported ransomware use, exploit maturity is none, and EPSS is low and declining (0.0028 → 0.0022 over 30 days), so mass exploitation is unlikely; residual risk remains wherever untrusted DICOMDIR files are processed by unpatched pydicom. Upgrade urgency is driven by data sensitivity rather than active campaigns.

How an attack unfolds

An attacker supplies a DICOM File-set whose DICOMDIR sets ReferencedFileID to a path that, after resolution, lies outside the File-set root (for example via parent-directory components). A user or automated pipeline opens that File-set with vulnerable pydicom. The library confirms the target exists but does not verify it remains under the File-set root. Later public FileSet operations then read, copy, or in some cases move or delete that out-of-root path with the privileges of the pydicom process. No named threat actors or KEV activity are associated with this CVE.

How to fix it

Upgrade pydicom to 3.0.2 or later, which confines ReferencedFileID resolution to the File-set root. Pin and rebuild all applications, containers, and imaging pipelines that depend on pydicom. Until upgraded, do not process untrusted DICOMDIR/File-set input, run pydicom under a least-privilege account with a narrow working directory, and block inbound File-sets from untrusted sources. There is no complete configuration workaround in affected 2.0.0-rc.1–3.0.1 releases.

How to confirm the fix worked

Confirm installed pydicom is 3.0.2 or newer (package metadata, lockfiles, container images, and runtime imports). After upgrade, only trusted File-sets should be processed, and FileSet operations must refuse ReferencedFileID values that would resolve outside the File-set root. Hunt lockfiles and images for pydicom versions in 2.0.0-rc.1 through 3.0.1 and treat those deployments as exposed until rebuilt.

Typical attack path

1. Craft or modify a DICOMDIR so ReferencedFileID resolves outside the File-set root.
2. Deliver the File-set to a user or pipeline that uses pydicom 2.0.0-rc.1 through 3.0.1.
3. Induce processing that calls FileSet copy(), write(), or remove()+write(use_existing=True).
4. pydicom uses the unbounded resolved path for file I/O.
5. Attacker-chosen files outside the File-set are read, copied, moved, or deleted under the host process identity.

How to detect it

There is no public exploit maturity and no named actor activity, so look for suspicious File-set handling rather than a known implant. Review application and audit logs around pydicom FileSet copy, write, and remove operations; inspect ingested DICOMDIR objects for ReferencedFileID values that contain parent-directory components or absolute paths outside the File-set root; and correlate with unexpected reads, copies, moves, or deletes of non-DICOM files by Python processes that import pydicom. Host telemetry of interest includes Python workers in imaging pipelines touching files outside approved study storage shortly after a DICOMDIR was opened. Absence of these artifacts does not prove non-exploitation if logging is incomplete.

• ReferencedFileID values containing ../
• ReferencedFileID values containing ..\
• DICOMDIR ReferencedFileID set to an absolute path outside the File-set root
• pydicom FileSet.copy/write/remove followed by I/O on paths outside the imaging File-set
• Python processes importing pydicom then unlink/rename of non-DICOM files after DICOMDIR parse

What your security team should do

• Inventory every runtime, image, and lockfile using pydicom 2.0.0-rc.1 through 3.0.1 and schedule upgrade to 3.0.2 or later.
• Stop ingesting untrusted DICOMDIR/File-set content until those runtimes are patched.
• Run remaining pydicom workloads with least privilege and filesystem allowlists limited to intended imaging storage.
• Review imaging and application logs for FileSet copy/write/remove activity against paths outside approved DICOM roots.
• Track this CVE as a patch-hygiene item rather than an active KEV/ransomware emergency, given low EPSS, no KEV listing, and no known exploit maturity.