CVE-2026-49254 in Dragonfly
Summary
by MITRE • 09/15/2026
Dragonfly is an open source P2P-based file distribution and image acceleration system. Prior to 2.4.4, manager/router/router.go registers GET /api/v1/oauth and GET /api/v1/oauth/:id without jwt.MiddlewareFunc() or RBAC(), while manager/handlers/oauth.go returns models.Oauth records and manager/models/oauth.go exposes Oauth.ClientSecret as client_secret in JSON. When an administrator has configured a GitHub or Google OAuth provider, an unauthenticated network client can reach GetOauth or GetOauths, load the stored models.Oauth record, and obtain the provider's client secret, client identifier, and redirect URL. The earlier GHSA-j8hf-cp34-g4j7 remediation protected the /jobs group only and did not protect these OAuth GET handlers. Disclosure of client_secret can enable abuse of the configured identity-provider integration, subject to the provider's redirect URI restrictions. This issue is fixed in 2.4.4.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/15/2026
Dragonfly is an open-source peer-to-peer file distribution and image acceleration system designed to optimize data transfer efficiency across distributed environments. A critical security vulnerability was identified within versions prior to 2.4.4, specifically affecting the authentication and authorization mechanisms governing OAuth provider configurations. The flaw stems from a misconfiguration in the HTTP routing layer where endpoints for retrieving OAuth records were registered without applying necessary middleware functions such as jwt.MiddlewareFunc() or Role-Based Access Control RBAC checks. This oversight allows unauthenticated network clients to access sensitive administrative data by directly invoking GET requests against /api/v1/oauth and /api/v1/oauth/:id paths, bypassing the intended authentication gates that should restrict access to authorized administrators only.
The technical root cause lies in the handler implementation within manager/handlers/oauth.go which returns models.Oauth records as JSON responses. Crucially, the model definition in manager/models/oauth.go exposes the Oauth.ClientSecret field directly under the name client_secret in its serialization output. When an administrator has previously configured identity providers such as GitHub or Google for authentication purposes, these endpoints inadvertently expose not only the client identifier and redirect URI but also the highly sensitive client secret associated with those integrations. This disclosure occurs because the routing configuration failed to enforce access controls on these specific read operations, leaving them open to any network actor capable of reaching the Dragonfly manager service.
The operational impact of this vulnerability is significant as it enables an unauthenticated attacker to harvest credentials required for abuse of the configured identity-provider integration. Although the disclosed client secret alone may not allow immediate account takeover due to provider-specific redirect URI restrictions, it provides the necessary components for sophisticated attacks such as OAuth token interception or phishing campaigns tailored to the specific organization's authentication flow. The earlier remediation referenced in GHSA-j8hf-cp34-g4j7 addressed security gaps in the /jobs group but did not extend protections to these OAuth GET handlers, leaving this attack vector open despite previous patching efforts. This highlights a common challenge in incremental security fixes where partial coverage can leave residual risks if comprehensive endpoint auditing is not performed.
From an industry standards perspective, this vulnerability aligns with CWE-284 Improper Access Control and CWE-798 Use of Hard-coded Credentials or Sensitive Data Exposure depending on the specific context of secret management. In terms of attack taxonomy, it corresponds to ATT&CK technique T1530 Data from Cloud Storage Objects as well as T1078 Valid Accounts if the attacker leverages stolen credentials for further lateral movement. The exposure of client secrets violates fundamental principles of least privilege and secure API design where sensitive configuration data should never be returned in unauthenticated responses regardless of the endpoint's intended administrative purpose.
To mitigate this risk, organizations running Dragonfly versions prior to 2.4.4 must upgrade immediately to version 2.4.4 or later which includes the necessary middleware enforcement for OAuth endpoints. For environments where immediate upgrading is not feasible, network-level controls such as firewall rules restricting access to the manager API ports should be implemented to ensure only trusted administrative networks can reach these endpoints. Additionally, it is recommended that administrators rotate all exposed client secrets immediately after patching or applying mitigations to invalidate any potentially harvested credentials. Future development processes should incorporate automated security testing for authentication middleware coverage across all API routes to prevent similar oversights in subsequent releases.