https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 13 Oct 2026 07:10:35 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-276689 EUVD-2026-276689 https://cve.radiocsirt.org/vuln/euvd-2026-276689 https://cve.radiocsirt.org/vuln/fkie_cve-2026-32711 <p>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.</p> <p>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.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-32711 https://cve.radiocsirt.org/vuln/ghsa-v856-2rf8-9f28 <p><strong>Affected:</strong> PyPI: pydicom</p> <p>### 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.</p> <p>### Details Verified on `pydicom 3.1.0.dev0`.</p> <p>Relevant logic is in `src/pydicom/fileset.py`:</p> <p>- `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(...)`</p> <p>Because there is no containment check such as `resolved.relative_to(root.resolve(strict=True))`, a malicious `DICOMDIR` can reference:</p> <p>- absolute paths such as `/etc/passwd` - traversal paths such as `../...` - syntactically conformant file IDs that escape via symlinks</p> <p>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…</p> <p><strong>Affected:</strong> PyPI: pydicom</p> <p>### 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.</p> <p>### Details Verified on `pydicom 3.1.0.dev0`.</p> <p>Relevant logic is in `src/pydicom/fileset.py`:</p> <p>- `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(...)`</p> <p>Because there is no containment check such as `resolved.relative_to(root.resolve(strict=True))`, a malicious `DICOMDIR` can reference:</p> <p>- absolute paths such as `/etc/passwd` - traversal paths such as `../...` - syntactically conformant file IDs that escape via symlinks</p> <p>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…</p> https://cve.radiocsirt.org/vuln/ghsa-v856-2rf8-9f28 https://cve.radiocsirt.org/vuln/opensuse-su-2026:10412-1 <p>python311-pydicom-3.0.2-1.1 on GA media</p> <p>python311-pydicom-3.0.2-1.1 on GA media</p> https://cve.radiocsirt.org/vuln/opensuse-su-2026:10412-1 https://cve.radiocsirt.org/vuln/pysec-2026-2266 <p><strong>Affected:</strong> PyPI: pydicom</p> <p>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.</p> <p><strong>Affected:</strong> PyPI: pydicom</p> <p>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.</p> https://cve.radiocsirt.org/vuln/pysec-2026-2266 https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-32711 <p><strong>Affected:</strong> 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</p> <p>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.</p> <p><strong>Affected:</strong> 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</p> <p>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.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-32711