CVE-2025-59352 is a critical (CVSS 9.8) path traversal in the Dragonfly gRPC and HTTP peer APIs before version 2.1.0. A peer can make another peer write and read arbitrary files, which can lead to code execution. Upgrade to 2.1.0. There is no workaround.
What's affected
Per GitHub advisory GHSA-79hx-3fp8-hj66, Dragonfly versions before 2.1.0 are affected, for both the github.com/dragonflyoss/dragonfly and d7y.io/dragonfly/v2 Go modules. The fix is in 2.1.0.
The advisory says there are no effective workarounds beyond upgrading.
How to check if you're exposed
Find your Dragonfly components and their versions. The advisory says everything before 2.1.0 is affected.
kubectl get pods -A -o jsonpath='{..image}' | tr ' ' '\n' | grep -i dragonfly | sort -u
For Go builds that import the module, check the module version:
go list -m all | grep -i dragonfly
The advisory lists both github.com/dragonflyoss/dragonfly and d7y.io/dragonfly/v2 as affected module paths.
What to do now
- Upgrade every Dragonfly peer and the Manager to 2.1.0 or later.
- Limit which hosts can reach the peer gRPC and HTTP ports to your own peer network.
- Run the peer processes as a low privileged user with a restricted file system view.
- Review hosts running peers for unexpected files and rotate any secrets stored on them.
- Confirm the running version after the rollout, not just the chart or image tag you intended.
Why it matters
The record maps this to CWE-22, path traversal, and CWE-202, exposure of sensitive information through data queries. The advisory shows that the data file path comes from a request and is opened for writing without being confined to the intended directory.
In a peer to peer system, trust between peers is the weak point. If any peer, or anything that can speak the peer protocol, can drive file operations on the others, one compromised node becomes a way into all of them. This CVE is not on the CISA KEV list. As with the sibling CVE-2025-59345, the finding came from a third party audit according to the advisory.
Path traversal weaknesses arise when a program builds a file path from input it does not control and does not confirm the result stays inside the intended directory. Depending on whether the code reads or writes, the outcome is disclosure of files or the placement of files where they should not be.
The standard defence is to resolve the final path, compare it against the allowed base directory, and refuse anything outside it. Running the service as an unprivileged user, with a file system that only exposes what it needs, limits how far a mistake can reach.
If you run Dragonfly to speed up container image distribution, the hosts that run peers are often build or cluster nodes with valuable credentials. That raises the stakes of a file read primitive and is a good reason to treat the upgrade as urgent.
Safeguard can help you find this one in your own software. The free in-browser dependency scan at gold.safeguard.sh/scan reads your manifest or lockfile and shows which known vulnerabilities your declared dependencies carry, including transitive ones. Reachability analysis then helps you separate the places where your code actually calls the affected component from the places where it only sits in the tree, which makes it easier to decide what to patch first.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
What does a malicious peer get?
Per the advisory, the ability to make a recipient peer create files in arbitrary locations and read arbitrary files, which can expose secrets and lead to code execution.
Is there a fix?
Yes, Dragonfly 2.1.0 and above.
Sources
- GitHub advisory GHSA-79hx-3fp8-hj66
- NVD record data
Last reviewed: 18 October 2026.
