Description

Dify before 1.15.0 contains a server-side request forgery vulnerability that allows any authenticated console user to bypass SSRF protections and issue arbitrary HTTP requests to internal services and cloud metadata endpoints due to the Squid proxy configuration only defining source ACLs without destination deny rules and the make_request() helper performing no independent destination IP validation. Attackers can use endpoints such as GET /console/api/remote-files/<url>, POST /console/api/remote-files/upload, the HTTP Request workflow node, website crawl, or document import from URL to reach internal components like the sandbox, internal APIs, and PostgreSQL, and on AWS deployments read IAM credentials from the instance metadata service, with the HTTP Request node further enabling POST, PUT, and DELETE writes to internal services relying on network isolation for authorization.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.6",
  "pubDate": "2026-11-06T16:18:54.697Z",
  "pubdate": "2026-11-06T16:18:54.697Z",
  "executiveSummary": "Dify versions prior to 1.15.0 are susceptible to a Server-Side Request Forgery (SSRF) vulnerability. This flaw stems from insufficient validation within the application's request-handling architecture and an improperly configured Squid proxy.\nThe vulnerability allows an authenticated console user to bypass existing SSRF protections, enabling the issuance of arbitrary HTTP requests to internal network segments, services, and cloud provider metadata endpoints.\nThe impact is significant, as it grants attackers the ability to probe internal APIs, interact with local services like PostgreSQL, or extract sensitive information, such as IAM credentials on AWS deployments.\nFurthermore, the HTTP Request workflow node facilitates arbitrary HTTP methods (POST, PUT, DELETE), potentially allowing an attacker to modify internal service states that rely on implicit trust through network isolation.\nExploitation requires a valid user account within the Dify console. Given the breadth of reachable endpoints and the potential for internal infrastructure compromise, the risk level is high, necessitating immediate remediation through patching or robust network-level ingress/egress filtering.",
  "technicalDetails": "The vulnerability resides in the interaction between the application's request dispatching logic and the backend proxy configuration. Specifically, the Squid proxy implementation relies solely on source-based Access Control Lists (ACLs) while failing to implement necessary destination-based deny rules. This allows traffic originating from the authorized proxy to reach restricted internal network ranges.\nSimultaneously, the internal make_request() helper function fails to perform independent validation of the destination IP address or domain. By providing malicious input to application endpoints such as /console/api/remote-files/<url>, /console/api/remote-files/upload, or utilizing the HTTP Request workflow node, website crawl, and document import features, an attacker can coerce the server into acting as a proxy for unauthorized requests.\nThe attack flow proceeds as follows: First, the attacker authenticates to the Dify console. Second, they craft a request to a legitimate application feature that triggers an outbound HTTP call. By manipulating the URL parameter or node configuration, the attacker redirects the request toward internal infrastructure (e.g., 169.254.169.254 for cloud metadata or internal service IP addresses). Third, because the make_request() function lacks destination filtering and the Squid proxy lacks restrictive egress rules, the request is permitted to reach the target internal service.\nThe scope of impact is extended significantly by the HTTP Request workflow node, which supports multiple HTTP methods. This enables an attacker to move beyond read-only operations and perform unauthorized write or delete actions against internal services that assume network-level security is sufficient for authorization. On cloud-hosted environments, this vulnerability directly facilitates the exfiltration of sensitive IAM instance profile credentials.\nAffected versions include all releases of Dify prior to 1.15.0. The vulnerability is fundamentally a failure to implement a 'deny-by-default' strategy for egress traffic and a lack of rigorous input sanitization regarding resolved destination IP addresses at the application layer."
}