pydicom is a pure Python package for working with DICOM files. Versions 2.0.0-rc.1 through 3.0.1 are vulnerable to Path Traversal through a maliciously crafted DICOMDIR ReferencedFileID when it is set to a path outside the File-set root. pydicom resolves the path only to confirm that it exists, but does not verify that the resolved path remains under the File-set root. Subsequent public FileSet operations such as copy(), write(), and remove()+write(use_existing=True) use that unchecked path in file I/O operations. This allows arbitrary file read/copy and, in some flows, move/delete outside the File-set root. This issue has been fixed in version 3.0.2.

Affected: PyPI: pydicom

### Summary A crafted `DICOMDIR` can set `ReferencedFileID` to a path outside the File-set root. `pydicom` resolves the path only to confirm that it exists, but does not verify that the resolved path remains under the File-set root. Subsequent public `FileSet` operations such as `copy()`, `write()`, and `remove()+write(use_existing=True)` use that unchecked path in file I/O operations. This allows arbitrary file read/copy and, in some flows, move/delete outside the File-set root.

### Details Verified on `pydicom 3.1.0.dev0`.

Relevant logic is in `src/pydicom/fileset.py`:

- `RecordNode._file_id` converts `ReferencedFileID` directly to `Path(...)` - `FileSet.load()` checks only `(root / file_id).resolve(strict=True)` to confirm existence - `FileSet.load()` does not verify that the final resolved path is contained within the File-set root - `FileInstance.path` returns `self.file_set.path / self.node._file_id` - `FileSet.copy()` uses `shutil.copyfile(instance.path, dst)` - `FileSet.write()` uses `Path(instance.path).unlink()` and `shutil.move(...)`

Because there is no containment check such as `resolved.relative_to(root.resolve(strict=True))`, a malicious `DICOMDIR` can reference:

- absolute paths such as `/etc/passwd` - traversal paths such as `../...` - syntactically conformant file IDs that escape via symlinks

This is not limited to obviously invalid VR input. Even when `pydicom` emits warnings for invalid `ReferencedFileID` values, the operation is not blocked. I also…

python311-pydicom-3.0.2-1.1 on GA media

Affected: PyPI: pydicom

pydicom is a pure Python package for working with DICOM files. Versions 2.0.0-rc.1 through 3.0.1 are vulnerable to Path Traversal through a maliciously crafted DICOMDIR ReferencedFileID when it is set to a path outside the File-set root. pydicom resolves the path only to confirm that it exists, but does not verify that the resolved path remains under the File-set root. Subsequent public FileSet operations such as copy(), write(), and remove()+write(use_existing=True) use that unchecked path in file I/O operations. This allows arbitrary file read/copy and, in some flows, move/delete outside the File-set root. This issue has been fixed in version 3.0.2.

Affected: Ubuntu:16.04:LTS: pydicom, Ubuntu:18.04:LTS: pydicom, Ubuntu:20.04:LTS: pydicom, Ubuntu:22.04:LTS: pydicom, Ubuntu:24.04:LTS: pydicom, Ubuntu:25.10: pydicom, Ubuntu:26.04:LTS: pydicom

pydicom is a pure Python package for working with DICOM files. Versions 2.0.0-rc.1 through 3.0.1 are vulnerable to Path Traversal through a maliciously crafted DICOMDIR ReferencedFileID when it is set to a path outside the File-set root. pydicom resolves the path only to confirm that it exists, but does not verify that the resolved path remains under the File-set root. Subsequent public FileSet operations such as copy(), write(), and remove()+write(use_existing=True) use that unchecked path in file I/O operations. This allows arbitrary file read/copy and, in some flows, move/delete outside the File-set root. This issue has been fixed in version 3.0.2.