How severe is GHSA-v856-2rf8-9f28?

GHSA-v856-2rf8-9f28 has a CVSS score of 7.8/10, rated HIGH. Immediate patching is strongly recommended.

Which packages are affected by GHSA-v856-2rf8-9f28?

GHSA-v856-2rf8-9f28 affects the following packages: pydicom (PyPI), pydicom (PyPI). Ecosystems affected: PyPI.

How do I fix GHSA-v856-2rf8-9f28?

Update pydicom to 3.0.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-v856-2rf8-9f28 is resolved across your whole dependency graph.

How do I detect GHSA-v856-2rf8-9f28 in my PyPI dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for pydicom. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

How do I mitigate GHSA-v856-2rf8-9f28 if there is no patch (or I can't update yet)?

If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

How does O3 Security protect against GHSA-v856-2rf8-9f28?

O3 pinpoints whether GHSA-v856-2rf8-9f28 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Is GHSA-v856-2rf8-9f28 actively exploited in the wild?

No public exploit code has been indexed for GHSA-v856-2rf8-9f28 yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

What is the EPSS score for GHSA-v856-2rf8-9f28?

GHSA-v856-2rf8-9f28 has an EPSS (Exploit Prediction Scoring System) score of 0.3%, placing it in the 19th percentile of all CVEs. EPSS is maintained by FIRST.org and estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. This score indicates relatively lower exploitation probability, though the CVSS severity should still guide your patching priority.

What type of vulnerability is GHSA-v856-2rf8-9f28?

GHSA-v856-2rf8-9f28 is classified as Path Traversal (CWE-22). This weakness type describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation. This is a high-impact weakness class that often enables remote code execution or data exposure.

When was GHSA-v856-2rf8-9f28 published, and has it been updated?

GHSA-v856-2rf8-9f28 was published on March 20, 2026 and was last updated on March 20, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

🐍 PyPI

GHSA-v856-2rf8-9f28

HIGH

pydicom has a path traversal in FileSet/DICOMDIR ReferencedFileID allows file access outside the File-set root

Also known asCVE-2026-32711

Published

Mar 20, 2026

Updated

Mar 20, 2026

Affected

2 pkgs

Patched

2 / 2

Exploits

None indexed

EPSS Exploitation Probability

via FIRST.org ↗

0.3%probability of exploitation in next 30 days

Lower Risk19th percentile+0.27%

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

Blast Radius

2 pkgs affected

🐍pydicom🐍pydicom

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.

Description

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 confirmed a symlink-based variant using a conformant file ID.

A realistic server-side scenario is:

a user uploads a DICOM File-set zip
the server loads the uploaded DICOMDIR using FileSet
the server re-exports or reorganizes the File-set using FileSet.copy() or FileSet.write()
a server-local file referenced by the malicious DICOMDIR is included in the exported result

PoC

Minimal reproduction:

Copy a sample File-set that contains a valid DICOMDIR
Modify one DirectoryRecordSequence item so that ReferencedFileID = "/etc/passwd" (or /tmp/secret.txt)
Load it with FileSet(ds) or FileSet(path_to_dicomdir)
Call FileSet.copy(new_root)
Observe that the exported File-set contains the contents of the referenced external file

Example:

from pathlib import Path
from tempfile import mkdtemp
import shutil
from pydicom import dcmread
from pydicom.fileset import FileSet

base = Path("src/pydicom/data/test_files/dicomdirtests")
root = Path(mkdtemp(prefix="fsroot_"))
out = Path(mkdtemp(prefix="fsout_"))

shutil.copy2(base / "DICOMDIR", root / "DICOMDIR")
for d in ("77654033", "98892003", "98892001"):
    shutil.copytree(base / d, root / d)

ds = dcmread(root / "DICOMDIR")
item = next(x for x in ds.DirectoryRecordSequence if "ReferencedFileID" in x)
item.ReferencedFileID = "/etc/passwd"

fs = FileSet(ds)
fs.copy(out)

I 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.

If useful, I can provide the exact malicious sample and the demo environment separately.

Impact

This is a path traversal / root containment bypass in FileSet handling.

Observed impact:

arbitrary file read/copy outside the File-set root via FileSet.copy() arbitrary file move outside the File-set root via FileSet.write() arbitrary file delete outside the File-set root via FileSet.remove(...); write(use_existing=True) Affected applications are those that accept untrusted DICOMDIR / File-set input and then call public FileSet workflows such as load(), copy(), write(), or remove().

A realistic impact is server-side file disclosure in import/export workflows.

Affected Packages

2 total 2 fixed

Ecosystem	Package	Vulnerable range	Fix
🐍PyPI	`pydicom`	≥ 3.0.0&&< 3.0.2	3.0.2
🐍PyPI	`pydicom`	all versions	2.4.5

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for pydicom. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update pydicom to 3.0.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-v856-2rf8-9f28 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-v856-2rf8-9f28 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-v856-2rf8-9f28. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### 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

O3 Security · Impact-Aware SCA

Is GHSA-v856-2rf8-9f28 in your dependencies?

O3 detects GHSA-v856-2rf8-9f28 across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works