{"id":"CVE-2026-32711","aliases":["ALPINE-CVE-2026-32711","DEBIAN-CVE-2026-32711","EUVD-2026-13433","GHSA-v856-2rf8-9f28","PYSEC-2026-2266","UBUNTU-CVE-2026-32711","openSUSE-SU-2026:10412-1"],"status":"published","title":"pydicom: Path traversal in FileSet/DICOMDIR ReferencedFileID allows file access outside the File-set root","description":"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.","severity":{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-11","score":0.00296,"percentile":0.22498,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-22"],"published":"2026-03-20T01:26:15Z","modified":"2026-11-03T06:33:02Z","fixes":[{"ecosystem":"PyPI","package":"pydicom","fixed_in":["3.0.2","2.4.5"],"sources":["ghsa","osv"]},{"ecosystem":"Alpine:v3.23","package":"py3-pydicom","fixed_in":["3.0.2-r0"],"sources":["osv"]},{"ecosystem":"Alpine:v3.24","package":"py3-pydicom","fixed_in":["3.0.2-r0"],"sources":["osv"]},{"ecosystem":"Debian:14","package":"pydicom","fixed_in":["3.0.2-1"],"sources":["osv"]},{"ecosystem":"openSUSE:Tumbleweed","package":"python-pydicom","fixed_in":["3.0.2-1.1"],"sources":["osv"]}],"affected":[{"source":"ghsa","ecosystem":"PyPI","package":"pydicom","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"3.0.0"},{"last_affected":"3.0.1"},{"fixed":"3.0.2"}]}]},{"source":"ghsa","ecosystem":"PyPI","package":"pydicom","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.4.5"}]}]},{"source":"osv","ecosystem":"Alpine:v3.23","package":"py3-pydicom","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.0.0"},{"fixed":"3.0.2-r0"}]}]},{"source":"osv","ecosystem":"Alpine:v3.24","package":"py3-pydicom","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.0.0"},{"fixed":"3.0.2-r0"}]}]},{"source":"osv","ecosystem":"Debian:12","package":"pydicom","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["2.3.1-1","2.4.3-1","2.4.3-2","2.4.3-3","3.0.2-1","3.0.2-2","3.0.2-3","3.0.2-4","3.0.2-5"]},{"source":"osv","ecosystem":"Debian:13","package":"pydicom","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["2.4.3-2","2.4.3-3","3.0.2-1","3.0.2-2","3.0.2-3","3.0.2-4","3.0.2-5"]},{"source":"osv","ecosystem":"Debian:14","package":"pydicom","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.0.2-1"}]}],"versions":["2.4.3-2","2.4.3-3"]},{"source":"osv","ecosystem":"PyPI","package":"pydicom","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"3.0.0"},{"fixed":"3.0.2"}]}],"versions":["3.0.0","3.0.1"]},{"source":"osv","ecosystem":"PyPI","package":"pydicom","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.4.5"}]}],"versions":["0.9.1","0.9.2","0.9.3","0.9.4-1","0.9.5","0.9.6","0.9.7","0.9.8","0.9.9","1.0.1","1.0.1rc1","1.0.2","1.1.0","1.2.0","1.2.0rc1","1.2.1","1.2.2","1.3.0","1.4.0","1.4.0rc1","1.4.1","1.4.2","2.0.0","2.0.0rc1","2.1.0","2.1.1","2.1.2","2.2.0","2.2.0rc1","2.2.1","2.2.2","2.3.0","2.3.1","2.4.0","2.4.1","2.4.2","2.4.3","2.4.4"]},{"source":"osv","ecosystem":"PyPI","package":"pydicom","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.0.0"},{"fixed":"3.0.2"}]}],"versions":["2.0.0","2.1.0","2.1.1","2.1.2","2.2.0","2.2.0rc1","2.2.1","2.2.2","2.3.0","2.3.1","2.4.0","2.4.1","2.4.2","2.4.3","2.4.4","2.4.5","3.0.0","3.0.0rc1","3.0.1"]},{"source":"osv","ecosystem":"Ubuntu:16.04:LTS","package":"pydicom","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["0.9.8-1","0.9.9-2"]},{"source":"osv","ecosystem":"Ubuntu:18.04:LTS","package":"pydicom","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["0.9.9-2","0.9.9-3"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"pydicom","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["1.2.1-1","1.4.1-1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"pydicom","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["2.0.0-1","2.0.0-2","2.2.2-1"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"pydicom","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["2.3.1-1","2.4.3-1"]},{"source":"osv","ecosystem":"Ubuntu:25.10","package":"pydicom","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["2.4.3-1","2.4.3-2"]},{"source":"osv","ecosystem":"Ubuntu:26.10","package":"pydicom","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["2.4.3-3","3.0.2-3"]},{"source":"osv","ecosystem":"Ubuntu:26.04:LTS","package":"pydicom","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["2.4.3-2","2.4.3-3"]},{"source":"osv","ecosystem":"openSUSE:Tumbleweed","package":"python-pydicom","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.0.2-1.1"}]}]}],"products":[{"vendor":"pydicom","product":"pydicom"}],"references":[{"url":"https://github.com/pydicom/pydicom/security/advisories/GHSA-v856-2rf8-9f28","tags":["x_refsource_CONFIRM","Exploit","Vendor Advisory","advisory","web","evidence","report"]},{"url":"https://github.com/pydicom/pydicom/commit/6414f01a053dff925578799f5a7208d2ae585e82","tags":["x_refsource_MISC","Patch","fix","web","report"]},{"url":"https://github.com/pydicom/pydicom/releases/tag/v3.0.2","tags":["x_refsource_MISC","Product","Release Notes","web","advisory","report"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-32711","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-v856-2rf8-9f28"},{"url":"https://security.alpinelinux.org/vuln/CVE-2026-32711","tags":["advisory"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/32xxx/CVE-2026-32711.json","tags":["advisory"]},{"url":"https://security-tracker.debian.org/tracker/CVE-2026-32711","tags":["advisory"]},{"url":"https://github.com/pydicom/pydicom","tags":["package"]},{"url":"https://ubuntu.com/security/CVE-2026-32711","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-32711","tags":["report"]},{"url":"","tags":["advisory"]},{"url":"https://www.suse.com/security/cve/CVE-2026-32711","tags":["web"]}],"sources":{"cve":[{"id":"CVE-2026-32711","title":"pydicom: Path traversal in FileSet/DICOMDIR ReferencedFileID allows file access outside the File-set root","description":"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.","status":"published","published":"2026-03-20T01:26:15.182Z","modified":"2026-03-20T16:41:56.917Z","cvss":[{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H","level":"high","assessor":"cna"}],"cwes":["CWE-22"],"updated_at":"2026-11-02T14:19:57.100857Z"}],"euvd":[{"id":"EUVD-2026-13433","description":"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.","status":"published","published":"2026-03-20T01:26:15Z","modified":"2026-03-20T16:41:56Z","cvss":[{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H","level":"high"}],"updated_at":"2026-11-02T19:25:32.04432Z"}],"ghsa":[{"id":"GHSA-v856-2rf8-9f28","title":"pydicom has a path traversal in FileSet/DICOMDIR ReferencedFileID allows file access outside the File-set root","description":"### Summary\nA 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.\n\n### Details\nVerified on `pydicom 3.1.0.dev0`.\n\nRelevant logic is in `src/pydicom/fileset.py`:\n\n- `RecordNode._file_id` converts `ReferencedFileID` directly to `Path(...)`\n- `FileSet.load()` checks only `(root / file_id).resolve(strict=True)` to confirm existence\n- `FileSet.load()` does not verify that the final resolved path is contained within the File-set root\n- `FileInstance.path` returns `self.file_set.path / self.node._file_id`\n- `FileSet.copy()` uses `shutil.copyfile(instance.path, dst)`\n- `FileSet.write()` uses `Path(instance.path).unlink()` and `shutil.move(...)`\n\nBecause there is no containment check such as `resolved.relative_to(root.resolve(strict=True))`, a malicious `DICOMDIR` can reference:\n\n- absolute paths such as `/etc/passwd`\n- traversal paths such as `../...`\n- syntactically conformant file IDs that escape via symlinks\n\nThis is not limited to obviously invalid VR input. Even when `pydicom` emits warnings for invalid `ReferencedFileID` values, the operation is not blocked. I also confirmed a symlink-based variant using a conformant file ID.\n\nA realistic server-side scenario is:\n\n1. a user uploads a DICOM File-set zip\n2. the server loads the uploaded `DICOMDIR` using `FileSet`\n3. the server re-exports or reorganizes the File-set using `FileSet.copy()` or `FileSet.write()`\n4. a server-local file referenced by the malicious `DICOMDIR` is included in the exported result\n\n### PoC\nMinimal reproduction:\n\n1. Copy a sample File-set that contains a valid `DICOMDIR`\n2. Modify one `DirectoryRecordSequence` item so that `ReferencedFileID = \"/etc/passwd\"` (or `/tmp/secret.txt`)\n3. Load it with `FileSet(ds)` or `FileSet(path_to_dicomdir)`\n4. Call `FileSet.copy(new_root)`\n5. Observe that the exported File-set contains the contents of the referenced external file\n\nExample:\n\n```python\nfrom pathlib import Path\nfrom tempfile import mkdtemp\nimport shutil\nfrom pydicom import dcmread\nfrom pydicom.fileset import FileSet\n\nbase = Path(\"src/pydicom/data/test_files/dicomdirtests\")\nroot = Path(mkdtemp(prefix=\"fsroot_\"))\nout = Path(mkdtemp(prefix=\"fsout_\"))\n\nshutil.copy2(base / \"DICOMDIR\", root / \"DICOMDIR\")\nfor d in (\"77654033\", \"98892003\", \"98892001\"):\n    shutil.copytree(base / d, root / d)\n\nds = dcmread(root / \"DICOMDIR\")\nitem = next(x for x in ds.DirectoryRecordSequence if \"ReferencedFileID\" in x)\nitem.ReferencedFileID = \"/etc/passwd\"\n\nfs = FileSet(ds)\nfs.copy(out)\n```\n\nI also verified the issue in a simple web import/export demo where an uploaded malicious File-set caused /etc/passwd to be copied into the exported result.\n\nIf useful, I can provide the exact malicious sample and the demo environment separately.\n\n### Impact\nThis is a path traversal / root containment bypass in FileSet handling.\n\nObserved impact:\n\narbitrary file read/copy outside the File-set root via FileSet.copy()\narbitrary file move outside the File-set root via FileSet.write()\narbitrary file delete outside the File-set root via FileSet.remove(...); write(use_existing=True)\nAffected applications are those that accept untrusted DICOMDIR / File-set input and then call public FileSet workflows such as load(), copy(), write(), or remove().\n\nA realistic impact is server-side file disclosure in import/export workflows.","status":"published","published":"2026-03-20T15:57:01Z","modified":"2026-03-20T15:57:02Z","cvss":[{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H","level":"high"}],"cwes":["CWE-22"],"updated_at":"2026-11-02T14:39:39.567266Z"}],"nvd":[{"id":"CVE-2026-32711","description":"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.","status":"published","published":"2026-03-20T02:16:33.6Z","modified":"2026-06-17T10:36:15.123Z","cvss":[{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H","level":"high","assessor":"secondary"}],"cwes":["CWE-22"],"updated_at":"2026-11-02T14:12:10.126802Z"}],"osv":[{"id":"ALPINE-CVE-2026-32711","description":"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.","status":"published","published":"2026-03-20T02:16:33.6Z","modified":"2026-11-03T06:33:02.354766Z","cvss":[{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H","level":"high"}],"updated_at":"2026-11-03T07:15:53.944853Z"},{"id":"CVE-2026-32711","title":"pydicom: Path traversal in FileSet/DICOMDIR ReferencedFileID allows file access outside the File-set root","description":"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.","status":"published","published":"2026-03-20T01:26:15.182Z","modified":"2026-10-28T02:30:31.574629762Z","cvss":[{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H","level":"high"}],"cwes":["CWE-22"],"updated_at":"2026-11-02T15:45:01.548715Z"},{"id":"DEBIAN-CVE-2026-32711","description":"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.","status":"published","published":"2026-03-20T02:16:33.6Z","modified":"2026-10-01T03:03:04.020895018Z","cvss":[{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H","level":"high"}],"updated_at":"2026-11-02T15:45:54.232518Z"},{"id":"GHSA-v856-2rf8-9f28","title":"pydicom has a path traversal in FileSet/DICOMDIR ReferencedFileID allows file access outside the File-set root","description":"### Summary\nA 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.\n\n### Details\nVerified on `pydicom 3.1.0.dev0`.\n\nRelevant logic is in `src/pydicom/fileset.py`:\n\n- `RecordNode._file_id` converts `ReferencedFileID` directly to `Path(...)`\n- `FileSet.load()` checks only `(root / file_id).resolve(strict=True)` to confirm existence\n- `FileSet.load()` does not verify that the final resolved path is contained within the File-set root\n- `FileInstance.path` returns `self.file_set.path / self.node._file_id`\n- `FileSet.copy()` uses `shutil.copyfile(instance.path, dst)`\n- `FileSet.write()` uses `Path(instance.path).unlink()` and `shutil.move(...)`\n\nBecause there is no containment check such as `resolved.relative_to(root.resolve(strict=True))`, a malicious `DICOMDIR` can reference:\n\n- absolute paths such as `/etc/passwd`\n- traversal paths such as `../...`\n- syntactically conformant file IDs that escape via symlinks\n\nThis is not limited to obviously invalid VR input. Even when `pydicom` emits warnings for invalid `ReferencedFileID` values, the operation is not blocked. I also confirmed a symlink-based variant using a conformant file ID.\n\nA realistic server-side scenario is:\n\n1. a user uploads a DICOM File-set zip\n2. the server loads the uploaded `DICOMDIR` using `FileSet`\n3. the server re-exports or reorganizes the File-set using `FileSet.copy()` or `FileSet.write()`\n4. a server-local file referenced by the malicious `DICOMDIR` is included in the exported result\n\n### PoC\nMinimal reproduction:\n\n1. Copy a sample File-set that contains a valid `DICOMDIR`\n2. Modify one `DirectoryRecordSequence` item so that `ReferencedFileID = \"/etc/passwd\"` (or `/tmp/secret.txt`)\n3. Load it with `FileSet(ds)` or `FileSet(path_to_dicomdir)`\n4. Call `FileSet.copy(new_root)`\n5. Observe that the exported File-set contains the contents of the referenced external file\n\nExample:\n\n```python\nfrom pathlib import Path\nfrom tempfile import mkdtemp\nimport shutil\nfrom pydicom import dcmread\nfrom pydicom.fileset import FileSet\n\nbase = Path(\"src/pydicom/data/test_files/dicomdirtests\")\nroot = Path(mkdtemp(prefix=\"fsroot_\"))\nout = Path(mkdtemp(prefix=\"fsout_\"))\n\nshutil.copy2(base / \"DICOMDIR\", root / \"DICOMDIR\")\nfor d in (\"77654033\", \"98892003\", \"98892001\"):\n    shutil.copytree(base / d, root / d)\n\nds = dcmread(root / \"DICOMDIR\")\nitem = next(x for x in ds.DirectoryRecordSequence if \"ReferencedFileID\" in x)\nitem.ReferencedFileID = \"/etc/passwd\"\n\nfs = FileSet(ds)\nfs.copy(out)\n```\n\nI also verified the issue in a simple web import/export demo where an uploaded malicious File-set caused /etc/passwd to be copied into the exported result.\n\nIf useful, I can provide the exact malicious sample and the demo environment separately.\n\n### Impact\nThis is a path traversal / root containment bypass in FileSet handling.\n\nObserved impact:\n\narbitrary file read/copy outside the File-set root via FileSet.copy()\narbitrary file move outside the File-set root via FileSet.write()\narbitrary file delete outside the File-set root via FileSet.remove(...); write(use_existing=True)\nAffected applications are those that accept untrusted DICOMDIR / File-set input and then call public FileSet workflows such as load(), copy(), write(), or remove().\n\nA realistic impact is server-side file disclosure in import/export workflows.","status":"published","published":"2026-03-20T15:57:01Z","modified":"2026-07-13T07:26:29.581553611Z","cvss":[{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H","level":"high"}],"cwes":["CWE-22"],"updated_at":"2026-11-02T15:46:56.981655Z"},{"id":"PYSEC-2026-2266","description":"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.","status":"published","published":"2026-03-20T02:16:33.6Z","modified":"2026-07-13T07:15:41.17678137Z","cvss":[{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H","level":"high"}],"updated_at":"2026-11-02T15:52:55.537808Z"},{"id":"UBUNTU-CVE-2026-32711","description":"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.","status":"published","published":"2026-03-20T02:16:00Z","modified":"2026-10-17T12:59:58.469126718Z","cvss":[{"version":"3.1","score":7.8,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H","level":"high"}],"updated_at":"2026-11-02T16:56:16.036833Z"},{"id":"openSUSE-SU-2026:10412-1","title":"python311-pydicom-3.0.2-1.1 on GA media","description":"These are all security issues fixed in the python311-pydicom-3.0.2-1.1 package on the GA media of openSUSE Tumbleweed.","status":"published","published":"2026-03-23T00:00:00Z","modified":"2026-03-24T08:45:06.984616Z","updated_at":"2026-11-02T16:58:38.415593Z"}]}}