CVE-2026-105762 in Dify
Summary
by MITRE • 10/06/2026
Dify is an open-source LLM app development platform. Prior to 1.13.0, the /console/api/remote-files/upload endpoint in api/controllers/web/remote_files.py accepted an attacker-controlled URL without authentication and caused the Dify server to retrieve it. A remote attacker could use the endpoint to send requests to internal services or cloud metadata endpoints, potentially exposing sensitive data and using the server as a network pivot. This issue is fixed in version 1.13.0.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/06/2026
The vulnerability identified in Dify versions prior to 1.13.0 represents a critical Server-Side Request Forgery (SSRF) flaw located within the remote file upload functionality of its web API controller. Specifically, the endpoint /console/api/remote-files/upload was designed to allow users to provide URLs for external resources that the server would subsequently fetch and process. However, due to insufficient input validation and a lack of authentication requirements on this specific path, an unauthenticated attacker could manipulate the URL parameter to point towards arbitrary destinations rather than legitimate public files. This architectural oversight allows the Dify application server itself to act as a proxy for network requests initiated by external actors, effectively bypassing standard perimeter security controls that might otherwise restrict direct access from outside networks.
From a technical perspective, this flaw enables an attacker to force the vulnerable server to send HTTP or other protocol requests to internal services running on localhost or within the same private network segment. Common targets include cloud metadata endpoints such as AWS EC2 Instance Metadata Service (IMDS) at 169.254.169.254, Azure Managed Identity endpoints, or Kubernetes service APIs. By accessing these sensitive interfaces, an attacker can retrieve IAM credentials, security tokens, and configuration data that are typically not exposed to the public internet but are accessible from within the host environment. This capability transforms a simple file upload feature into a powerful tool for lateral movement and privilege escalation within cloud infrastructure environments.
The operational impact of this vulnerability is severe, primarily centered on unauthorized access to sensitive internal resources and potential data exfiltration. If an attacker successfully exploits this SSRF condition against cloud metadata services, they can obtain temporary security credentials that grant them control over other AWS, Azure, or GCP resources associated with the compromised instance. This leads directly to a compromise of confidentiality and integrity for any data stored in linked storage buckets, databases, or compute instances. Furthermore, the ability to pivot through the Dify server allows attackers to probe internal network topologies, identify additional vulnerable services such as admin panels or database ports that are not publicly exposed, and potentially launch further attacks against these internal assets using the trusted identity of the application server.
This vulnerability aligns with CWE-918, which defines Server-Side Request Forgery (SSRF) flaws where a web application fetches a remote resource without validating the user-supplied URL. In terms of offensive security frameworks, this exploit maps to MITRE ATT&CK technique T1557, specifically Adversary-in-the-Middle or Lateral Tool Transfer variants that leverage SSRF for credential access and network reconnaissance. The lack of authentication on an endpoint capable of making outbound requests is a significant deviation from secure design principles, as it violates the principle of least privilege by allowing untrusted inputs to trigger privileged network operations without identity verification.
To mitigate this risk, organizations running Dify must immediately upgrade to version 1.13.0 or later, where the developers have implemented proper authentication checks and input validation for the remote file upload endpoint. For environments that cannot be patched instantly due to operational constraints, temporary mitigations should include placing a reverse proxy in front of the application to enforce strict access control lists on the /console/api/remote-files/upload path, ensuring only authenticated users can reach it. Additionally, implementing network-level controls such as egress filtering or web application firewalls that block outbound requests from the Dify server to known cloud metadata IP ranges and internal service CIDRs can significantly reduce the attack surface. It is also advisable to disable IMDSv1 on any associated EC2 instances if applicable, requiring IMDSv2 which uses session-based tokens that are harder for SSRF attacks to steal without additional context.