Dify prior to version 1.15.0 is vulnerable to server‑side request forgery. An authenticated console user can bypass the framework’s SSRF defenses and issue arbitrary HTTP requests. The flaw originates from the Squid proxy configuration, which defines only source ACLs without blocking destination addresses, and from a helper that performs no independent validation of target IPs. Attackers can call endpoints such as GET /console/api/remote-files/<url>, POST /console/api/remote-files/upload, or use the HTTP Request node, website crawl, or document import workflows to reach internal components like the sandbox, internal APIs, PostgreSQL, and, on AWS, the instance metadata service to retrieve IAM credentials. The use of HTTP Request also allows POST, PUT, and DELETE operations against protected services that rely on network isolation for authorization.

Impact is limited to installations of the langgenius Dify platform with a version less than 1.15.0. The product, available under the vendor langgenius, contains the SSRF bypass until the release of v1.15.0, which addressed the core configuration and validation issues. Any deployment before this version is considered vulnerable.

The vulnerability scores 7.2 on CVSS, indicating a medium to high severity. EPSS is not available, and the issue is not currently listed in CISA’s KEV catalog. Exploitation requires a legitimate authenticated console account, a typical role within the organization. Given that the attack vector leverages standard API endpoints and internal workflows, an attacker could request sensitive internal resources or credentials from cloud metadata services. Because the SSRF bypass can be used to issue arbitrary HTTP methods, the potential impact extends to confidentiality, integrity, and availability of internal services. Organizations with endpoint access should assess the exposure of internal endpoints and apply mitigations promptly.