CVE-2025-59346: Linuxfoundation Dragonfly SSRF Vulnerability

CVE-2025-59346 Overview

CVE-2025-59346 is a Server-Side Request Forgery (SSRF) vulnerability [CWE-918] in Dragonfly, an open source peer-to-peer (P2P) file distribution and image acceleration system maintained by the Linux Foundation. Versions prior to 2.1.0 allow attackers to force Dragonfly components to send HTTP requests to internal services that are otherwise unreachable. The Manager API accepts user-supplied URLs when creating Preheat jobs with weak validation. Peers can trigger other peers to fetch arbitrary URLs through pieceManager.DownloadSource, and the internal HTTP clients follow redirects to internal services. The issue is fixed in version 2.1.0.

Critical Impact
Attackers with network access to the Manager API can probe or access internal HTTP endpoints, exposing internal services that should not be reachable from the peer network.

Affected Products

Linux Foundation Dragonfly versions prior to 2.1.0
Dragonfly Manager API component
Dragonfly peer components using pieceManager.DownloadSource

Discovery Timeline

2025-09-17 - CVE-2025-59346 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-59346

Vulnerability Analysis

Dragonfly distributes files across peers using a manager service that orchestrates preheat jobs, seeding content across the cluster before it is requested. The vulnerability affects this preheat workflow. When a client submits a Preheat job to the Manager API, the request accepts a user-supplied URL that the manager forwards to peers. Peers then invoke pieceManager.DownloadSource to fetch the target URL. The URL is not restricted to expected external content sources, so an attacker can supply URLs that reference internal network addresses, cloud metadata services, or loopback interfaces. The vulnerability is tracked under CWE-918: Server-Side Request Forgery.

Root Cause

The root cause is weak input validation on the Manager API's Preheat URL parameter combined with permissive HTTP client behavior in the peer components. The internal HTTP clients follow HTTP redirects without restricting the destination host, so even if initial validation blocked internal hosts, an attacker-controlled external server can respond with a 3xx redirect that points at an internal service. This bypasses any origin-only filtering and lets requests reach services bound to private ranges or loopback.

Attack Vector

An unauthenticated network attacker submits a crafted Preheat job to the Manager API referencing an attacker-controlled URL. The Manager instructs peers to download from the URL. The attacker's server responds with an HTTP redirect targeting an internal endpoint such as http://127.0.0.1:6060/debug/pprof or a cloud metadata service. Peer HTTP clients follow the redirect, issue the request, and the response is observable through timing, error messages, or content returned to the requester. The vulnerability enables reconnaissance of internal services and potential access to unauthenticated internal HTTP endpoints.

No public proof-of-concept exploit is available at this time. Technical details are documented in the GitHub Security Advisory GHSA-g2rq-jv54-wcpr.

Detection Methods for CVE-2025-59346

Indicators of Compromise

Unexpected outbound HTTP requests from Dragonfly peer processes to loopback (127.0.0.1), link-local (169.254.169.254), or RFC1918 addresses.
Preheat job records in the Manager database containing URLs referencing internal IP ranges, unusual ports, or attacker-controlled domains.
Peer logs showing redirect chains from external URLs to internal hosts within pieceManager.DownloadSource operations.

Detection Strategies

Audit Manager API access logs for Preheat job submissions and correlate the submitted URLs against an allowlist of legitimate content origins.
Instrument peer processes to log the final destination of every DownloadSource request after redirect resolution, not only the originally submitted URL.
Deploy egress network monitoring to alert when Dragonfly components initiate connections to internal service ports such as metadata endpoints, admin consoles, or debug interfaces.

Monitoring Recommendations

Forward Dragonfly Manager and peer logs to a centralized log platform and build alerts for redirect responses whose target host differs from the submitted job URL host.
Monitor for anomalous HTTP status patterns from peer downloader components, particularly high volumes of short-lived requests to distinct internal hosts, which indicate SSRF-based scanning.
Track Preheat job creation rates and originating identities to identify accounts submitting abnormal volumes or URL patterns.

How to Mitigate CVE-2025-59346

Immediate Actions Required

Upgrade all Dragonfly Manager and peer components to version 2.1.0 or later, which contains the SSRF fix.
Restrict network access to the Manager API to authenticated internal callers only, using network policies or an authenticating reverse proxy.
Review recent Preheat job history for URLs that reference internal networks and investigate the corresponding peer logs for evidence of successful internal probing.

Patch Information

The vulnerability is fixed in Dragonfly version 2.1.0. Refer to the GitHub Security Advisory GHSA-g2rq-jv54-wcpr for details of the fix, and consult the Dragonfly Comprehensive Security Report for additional context on the project's security posture.

Workarounds

Where an immediate upgrade is not possible, place the Manager API behind an egress firewall that denies peer connections to loopback, link-local, and private address ranges.
Disable or restrict the Preheat job functionality if it is not required in the deployment.
Deploy an outbound proxy in front of peer components that enforces URL allowlisting and terminates or rewrites HTTP redirects before they reach the internal network.

bash

# Example egress restriction using iptables on a Dragonfly peer host
# Block peer process (uid 1500) from reaching internal ranges and metadata service
iptables -A OUTPUT -m owner --uid-owner 1500 -d 127.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner 1500 -d 169.254.169.254/32 -j REJECT
iptables -A OUTPUT -m owner --uid-owner 1500 -d 10.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner 1500 -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -m owner --uid-owner 1500 -d 192.168.0.0/16 -j REJECT