Skip to content

← Public intelligence

Go package

d7y.io/dragonfly/v2

Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.

Open advisories

15 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.

  1. Medium, CVSS 5.5GoPublished

    Dragonfly scheduler v1 and v2 gRPC unauthenticated SSRF via attacker-controlled PeerHost in DownloadTinyFile

    CVE-2026-54637 · GHSA-chwm-m7g7-685g

    Affected
    • Go d7y.io/dragonfly/v2 <= 2.4.4-rc.2
    Fixed in
    2.4.4-rc.3· Vendor fix available
    Issue
    The Dragonfly scheduler's v1 gRPC service contains an unauthenticated Server-Side Request Forgery (SSRF). When a peer reports a successful download of a TINY task, the scheduler calls Peer.DownloadTinyFile() and issues an HTTP GET to a host and port taken verbatim from the attacker-controlled PeerHost.Ip / PeerHost.DownPort fields of the gRPC request body. The HTTP client uses a bare http.Transport with no address validation, so a remote, unauthenticated client can force the scheduler to connect to arbitrary internal addresses, including 127.0.0.1 (loopback), 169.254.0.0/16 (link-local, e.g. cloud metadata), and RFC1918 ranges. The fetched response is stored in Task.DirectPiece and can subsequently be served to other peers, making this a read-SSRF with a data-exfiltration path. The manager's preheat code path already wraps its HTTP client with nethttp.NewSafeDialer() (which rejects non-global-unicast destinations); the scheduler's DownloadTinyFile path is missing this guard…

    Recommended action: Upgrade to 2.4.4-rc.3 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →
  2. Low, CVSS 2.9GoPublished

    Dragonfly Manager OAuth provider client_secret disclosure via unauthenticated GET /api/v1/oauth

    CVE-2026-49254 · GHSA-4q9j-6299-gxmr

    Affected
    • Go d7y.io/dragonfly/v2 <= 2.4.3
    Fixed in
    2.4.4· Vendor fix available
    Issue
    The Dragonfly Manager exposes GET /api/v1/oauth and GET /api/v1/oauth/:id to unauthenticated clients. The response body deserializes the entire manager/models.Oauth struct, which includes the clientsecret field. Any network-reachable attacker can read the OAuth client secrets configured for github or google providers, defeating the confidentiality guarantee of those secrets and enabling subsequent abuse against the connected identity providers. Affected versions github.com/dragonflyoss/dragonfly <= v2.4.3 (and current main at commit 46a8f1e). The vulnerable wiring is present back to the introduction of OAuth GET handlers and was not addressed by GHSA-j8hf-cp34-g4j7 / CVE-2026-24124, whose remediation only added jwt + rbac middleware to the /jobs group. Privilege required Unauthenticated. The only precondition is that an administrator has registered at least one OAuth provider via POST /api/v1/oauth (a one-time setup for tenants that enable GitHub / Google sign-in). Vulnerable…

    Recommended action: Upgrade to 2.4.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →
  3. High, CVSS 8.9GoPublished

    Dragonfly Manager Job API Unauthenticated Access

    CVE-2026-24124 · GHSA-j8hf-cp34-g4j7

    Affected
    • Go d7y.io/dragonfly/v2 < 2.4.1
    Fixed in
    2.4.1· Vendor fix available
    Issue
    Dragonfly Manager's Job REST API endpoints lack authentication, allowing unauthenticated attackers to create, query, modify, and delete jobs, potentially leading to resource exhaustion, information disclosure, and service disruption. Affected Products - Product: Dragonfly - Component: Manager (REST API) - Affected Versions: v2.x (based on source code analysis, including v2.4.0) - Affected Endpoints: /api/v1/jobs Vulnerability Details Description Dragonfly Manager's Job API endpoints (/api/v1/jobs) lack JWT authentication middleware and RBAC authorization checks in the routing configuration. This allows any unauthenticated user with access to the Manager API to perform the following operations: 1. List all jobs (GET /api/v1/jobs) 2. Create new jobs (POST /api/v1/jobs) 3. Query job details (GET /api/v1/jobs/:id) 4. Modify jobs (PATCH /api/v1/jobs/:id) 5. Delete jobs (DELETE /api/v1/jobs/:id) Technical Root Cause In the source code file manager/router/router.go at lines 204-211,…

    Recommended action: Upgrade to 2.4.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →
  4. Medium, CVSS 5.5GoPublished

    DragonFly's tiny file download uses hard coded HTTP protocol

    CVE-2025-59410 · GHSA-mcvp-rpgg-9273

    Affected
    • Go d7y.io/dragonfly/v2 < 2.1.0
    Fixed in
    2.1.0· Vendor fix available
    Issue
    Impact The code in the scheduler for downloading a tiny file is hard coded to use the HTTP protocol, rather than HTTPS. This means that an attacker could perform a Man-in-the-Middle attack, changing the network request so that a different piece of data gets downloaded. Due to the use of weak integrity checks (TOB-DF2-15), this modification of the data may go unnoticed. A network-level attacker who cannot join a peer-to-peer network performs a Man-in-the-Middle attack on peers. The adversary can do this because peers (partially) communicate over plaintext HTTP protocol. The attack chains this vulnerability with the one described in TOB-DF2-15 to replace correct files with malicious ones. Unconscious peers use the malicious files. Patches - Dragonfy v2.1.0 and above. Workarounds There are no effective workarounds, beyond upgrading. References A third party security audit was performed by Trail of Bits, you can see the full report. If you have any questions or comments about this…

    Recommended action: Upgrade to 2.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →
  5. Medium, CVSS 5.5GoPublished

    DragonFly has weak integrity checks for downloaded files

    CVE-2025-59354 · GHSA-hx2h-vjw2-8r54

    Affected
    • Go d7y.io/dragonfly/v2 < 2.1.0
    Fixed in
    2.1.0· Vendor fix available
    Issue
    Impact The DragonFly2 uses a variety of hash functions, including the MD5 hash. This algorithm does not provide collision resistance; it is secure only against preimage attacks. While these security guarantees may be enough for the DragonFly2 system, it is not completely clear if there are any scenarios where lack of the collision resistance would compromise the system. There are no clear benefits to keeping the MD5 hash function in the system. Alice, a peer in the DragonFly2 system, creates two images: an innocent one, and one with malicious code. Both images consist of two pieces, and Alice generates the pieces so that their respective MD5 hashes collide (are the same). Therefore, the PieceMd5Sign metadata of both images are equal. Alice shares the innocent image with other peers, who attest to their validity (i.e., that it works as expected and is not malicious). Bob wants to download the image and requests it from the peer-to-peer network. After downloading the image, Bob checks…

    Recommended action: Upgrade to 2.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →
  6. High, CVSS 7.7GoPublished

    DragonFly's manager generates mTLS certificates for arbitrary IP addresses

    CVE-2025-59353 · GHSA-255v-qv84-29p5

    Affected
    • Go d7y.io/dragonfly/v2 < 2.1.0
    Fixed in
    2.1.0· Vendor fix available
    Issue
    Impact A peer can obtain a valid TLS certificate for arbitrary IP addresses, effectively rendering the mTLS authentication useless. The issue is that the Manager’s Certificate gRPC service does not validate if the requested IP addresses “belong to” the peer requesting the certificate—that is, if the peer connects from the same IP address as the one provided in the certificate request. Patches - Dragonfy v2.1.0 and above. Workarounds There are no effective workarounds, beyond upgrading. References A third party security audit was performed by Trail of Bits, you can see the full report. If you have any questions or comments about this advisory, please email us at dragonfly-maintainers@googlegroups.com.

    Recommended action: Upgrade to 2.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →
  7. Medium, CVSS 6.9GoPublished

    DragonFly vulnerable to arbitrary file read and write on a peer machine

    CVE-2025-59352 · GHSA-79hx-3fp8-hj66

    Affected
    • Go d7y.io/dragonfly/v2 < 2.1.0
    Fixed in
    2.1.0· Vendor fix available
    Issue
    Impact A peer exposes the gRPC API and HTTP API for consumption by other peers. These APIs allow peers to send requests that force the recipient peer to create files in arbitrary file system locations, and to read arbitrary files. This allows peers to steal other peers’ secret data and to gain remote code execution (RCE) capabilities on the peer’s machine. Patches - Dragonfy v2.1.0 and above. Workarounds There are no effective workarounds, beyond upgrading. References A third party security audit was performed by Trail of Bits, you can see the full report. If you have any questions or comments about this advisory, please email us at dragonfly-maintainers@googlegroups.com.

    Recommended action: Upgrade to 2.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →
  8. Medium, CVSS 5.5GoPublished

    DragonFly vulnerable to panics due to nil pointer dereference when using variables created alongside an error

    CVE-2025-59351 · GHSA-4mhv-8rh3-4ghw

    Affected
    • Go d7y.io/dragonfly/v2 < 2.1.0
    Fixed in
    2.1.0· Vendor fix available
    Issue
    Impact We found two instances in the DragonFly codebase where the first return value of a function is dereferenced even when the function returns an error (figures 9.1 and 9.2). This can result in a nil dereference, and cause code to panic. The codebase may contain additional instances of the bug. Eve is a malicious actor operating a peer machine. She sends a dfdaemonv1.DownRequest request to her peer Alice. Alice’s machine receives the request, resolves a nil variable in the server.Download method, and panics. Patches - Dragonfy v2.1.0 and above. Workarounds There are no effective workarounds, beyond upgrading. References A third party security audit was performed by Trail of Bits, you can see the full report. If you have any questions or comments about this advisory, please email us at dragonfly-maintainers@googlegroups.com.

    Recommended action: Upgrade to 2.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →
  9. Medium, CVSS 5.5GoPublished

    Dragonfly vulnerable to timing attacks against Proxy’s basic authentication

    CVE-2025-59350 · GHSA-c2fc-9q9c-5486

    Affected
    • Go d7y.io/dragonfly/v2 < 2.1.0
    Fixed in
    2.1.0· Vendor fix available
    Issue
    Impact The access control mechanism for the Proxy feature uses simple string comparisons and is therefore vulnerable to timing attacks. An attacker may try to guess the password one character at a time by sending all possible characters to a vulnerable mechanism and measuring the comparison instruction’s execution times. The vulnerability is shown in figure 8.1, where both the username and password are compared with a short-circuiting equality operation. It is currently undetermined what an attacker may be able to do with access to the proxy password. Patches - Dragonfy v2.1.0 and above. Workarounds There are no effective workarounds, beyond upgrading. References A third party security audit was performed by Trail of Bits, you can see the full report. If you have any questions or comments about this advisory, please email us at dragonfly-maintainers@googlegroups.com.

    Recommended action: Upgrade to 2.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →
  10. Low, CVSS 2.0GoPublished

    Dragonfly's directories created via os.MkdirAll are not checked for permissions

    CVE-2025-59349 · GHSA-8425-8r2f-mrv6

    Affected
    • Go d7y.io/dragonfly/v2 < 2.1.0
    Fixed in
    2.1.0· Vendor fix available
    Issue
    Impact DragonFly2 uses the os.MkdirAll function to create certain directory paths with specific access permissions. This function does not perform any permission checks when a given directory path already exists. This allows a local attacker to create a directory to be used later by DragonFly2 with broad permissions before DragonFly2 does so, potentially allowing the attacker to tamper with the files. Eve has unprivileged access to the machine where Alice uses DragonFly2. Eve watches the commands executed by Alice and introduces new directories/paths with 0777 permissions before DragonFly2 does so. Eve can then delete and forge files in that directory to change the results of further commands executed by Alice. Patches - Dragonfy v2.1.0 and above. Workarounds There are no effective workarounds, beyond upgrading. References A third party security audit was performed by Trail of Bits, you can see the full report. If you have any questions or comments about this advisory, please email…

    Recommended action: Upgrade to 2.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →
  11. Medium, CVSS 5.5GoPublished

    Dragonfly incorrectly handles a task structure’s usedTrac field

    CVE-2025-59348 · GHSA-2qgr-gfvj-qpcr

    Affected
    • Go d7y.io/dragonfly/v2 < 2.1.0
    Fixed in
    2.1.0· Vendor fix available
    Issue
    Impact The processPieceFromSource method (figure 4.1) is part of a task processing mechanism. The method writes pieces of data to storage, updating a Task structure along the way. The method does not update the structure’s usedTraffic field, because an uninitialized variable n is used as a guard to the AddTraffic method call, instead of the result.Size variable. A task is processed by a peer. The usedTraffic metadata is not updated during the processing. Rate limiting is incorrectly applied, leading to a denial-of-service condition for the peer. Patches - Dragonfy v2.1.0 and above. Workarounds There are no effective workarounds, beyond upgrading. References A third party security audit was performed by Trail of Bits, you can see the full report. If you have any questions or comments about this advisory, please email us at dragonfly-maintainers@googlegroups.com.

    Recommended action: Upgrade to 2.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →
  12. Medium, CVSS 5.5GoPublished

    Dragonfly's manager makes requests to external endpoints with disabled TLS authentication

    CVE-2025-59347 · GHSA-98x5-jw98-6c97

    Affected
    • Go d7y.io/dragonfly/v2 < 2.1.0
    Fixed in
    2.1.0· Vendor fix available
    Issue
    Impact The Manager disables TLS certificate verification in two HTTP clients (figures 3.1 and 3.2). The clients are not configurable, so users have no way to re-enable the verification. A Manager processes dozens of preheat jobs. An adversary performs a network-level Man-in-the-Middle attack, providing invalid data to the Manager. The Manager preheats with the wrong data, which later causes a denial of service and file integrity problems. Patches - Dragonfy v2.1.0 and above. Workarounds There are no effective workarounds, beyond upgrading. References A third party security audit was performed by Trail of Bits, you can see the full report. If you have any questions or comments about this advisory, please email us at dragonfly-maintainers@googlegroups.com.

    Recommended action: Upgrade to 2.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →
  13. High, CVSS 7.7GoPublished

    Dragonfly vulnerable to server-side request forgery

    CVE-2025-59346 · GHSA-g2rq-jv54-wcpr

    Affected
    • Go d7y.io/dragonfly/v2 < 2.1.0
    Fixed in
    2.1.0· Vendor fix available
    Issue
    Impact There are multiple server-side request forgery (SSRF) vulnerabilities in the DragonFly2 system. The vulnerabilities enable users to force DragonFly2’s components to make requests to internal services, which otherwise are not accessible to the users. One SSRF attack vector is exposed by the Manager’s API. The API allows users to create jobs. When creating a Preheat type of a job, users provide a URL that the Manager connects to (see figures 2.1–2.3). The URL is weakly validated, and so users can trick the Manager into sending HTTP requests to services that are in the Manager’s local network. A second attack vector is in peer-to-peer communication. A peer can ask another peer to make a request to an arbitrary URL by triggering the pieceManager.DownloadSource method (figure 2.4), which calls the httpSourceClient.GetMetadata method, which performs the request. Another attack vector is due to the fact that HTTP clients used by the DragonFly2’s components do not disable support for…

    Recommended action: Upgrade to 2.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →
  14. High, CVSS 7.7GoPublished

    Dragonfly doesn't have authentication enabled for some Manager’s endpoints

    CVE-2025-59345 · GHSA-89vc-vf32-ch59

    Affected
    • Go d7y.io/dragonfly/v2 < 2.1.0
    Fixed in
    2.1.0· Vendor fix available
    Issue
    Impact The /api/v1/jobs and /preheats endpoints in Manager web UI are accessible without authentication. Any user with network access to the Manager can create, delete, and modify jobs, and create preheat jobs. An unauthenticated adversary with network access to a Manager web UI uses /api/v1/jobs endpoint to create hundreds of useless jobs. The Manager is in a denial-of-service state, and stops accepting requests from valid administrators. Patches - Dragonfy v2.1.0 and above. Workarounds There are no effective workarounds, beyond upgrading. References A third party security audit was performed by Trail of Bits, you can see the full report. If you have any questions or comments about this advisory, please email us at dragonfly-maintainers@googlegroups.com.

    Recommended action: Upgrade to 2.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →
  15. Critical, CVSS 9.3GoPublished

    Dragonfly2 has hard coded cyptographic key

    CVE-2023-27584 · GHSA-hpc8-7wpm-889w

    Affected
    • Go d7y.io/dragonfly/v2 >= 2.1.0-alpha.0, < 2.1.0-beta.1; < 2.0.9-rc.2
    Fixed in
    2.0.9-rc.22.1.0-beta.1· Vendor fix available
    Issue
    Hello dragonfly maintainer team, I would like to report a security issue concerning your JWT feature. Details Dragonfly uses JWT to verify user. However, the secret key for JWT, "Secret Key", is hard coded, which leads to authentication bypass PoC Use code below to generate a jwt token And send request with JWT above , you can still get data without restriction. <img width="1241" alt="image" src="https://user-images.githubusercontent.com/70683161/224255896-8604fa70-5846-4fa0-b1f9-db264c5865fe.png" Impact An attacker can perform any action as a user with admin privileges.

    Recommended action: Upgrade to 2.1.0-beta.1 (pre-release) or 2.0.9-rc.2 (pre-release) by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →