CVE-2026-58141 in Dify
Summary
by MITRE • 11/06/2026
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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 11/06/2026
The vulnerability identified in Dify versions prior to 1.15.0 represents a critical server-side request forgery flaw that fundamentally undermines the security boundary between authenticated console users and sensitive internal infrastructure. This issue stems from an incomplete implementation of proxy-based access controls, specifically within the Squid proxy configuration which relies exclusively on source address control lists while failing to enforce destination deny rules. Furthermore, the application-level helper function responsible for initiating network connections lacks independent validation of target IP addresses or domains. Consequently, any user with valid authentication credentials can manipulate the request parameters to redirect outbound traffic toward internal services and cloud metadata endpoints that are ostensibly protected by network segmentation or proxy policies.
The operational impact of this vulnerability is severe due to its broad applicability across multiple entry points within the Dify console interface. Attackers can exploit specific API endpoints such as GET /console/api/remote-files/ and POST /console/api/remote-files/upload, as well as functional features like the HTTP Request workflow node, website crawling capabilities, and document import from URL functionality. These vectors allow for arbitrary HTTP requests to be issued against internal components including sandbox environments, internal APIs, and database services such as PostgreSQL. The absence of destination validation means that network isolation mechanisms relying on implicit trust in source authentication are effectively bypassed, allowing lateral movement within the deployment environment.
In cloud-native deployments, particularly those running on Amazon Web Services, this vulnerability poses an existential risk to identity and access management security. By targeting the instance metadata service endpoint, attackers can retrieve IAM credentials associated with the underlying EC2 instances or other compute resources. The acquisition of these temporary security credentials grants unauthorized administrative privileges over AWS services, potentially leading to data exfiltration, resource manipulation, or further compromise of the cloud environment. Additionally, the HTTP Request node supports methods beyond simple retrieval, including POST, PUT, and DELETE operations. This capability enables attackers not only to read sensitive information but also to modify state on internal services that depend solely on network isolation for authorization controls, thereby facilitating destructive actions such as data deletion or configuration tampering.
From a classification perspective, this vulnerability aligns with CWE-918 Server-Side Request Forgery and specifically highlights the failure in implementing proper access control lists for outbound traffic, which relates to CWE-269 Improper Privilege Management when considering the bypass of network-based restrictions. In terms of adversary behavior, it maps directly to MITRE ATT&CK technique T1571 Non-Standard Port as well as T1078 Valid Accounts if leveraging existing credentials, and more critically T1534 Internal Spearphishing or lateral movement techniques depending on the target internal service. The exploitation path demonstrates how application-level logic flaws can negate infrastructure-layer security controls when destination validation is omitted.
Mitigation strategies must focus on both immediate remediation and long-term architectural improvements. The primary solution is to upgrade Dify to version 1.15.0 or later, where these proxy configurations and helper functions have been corrected to enforce strict destination allowlists or deny rules for sensitive internal ranges. For deployments that cannot immediately patch, administrators should implement additional network-level controls such as egress filtering at the firewall level to block outbound connections from application servers to cloud metadata endpoints like 169.254.169.254 and restrict access to internal database ports unless explicitly required by business logic. Application developers must also ensure that all HTTP client implementations perform rigorous validation of target URLs, rejecting requests with private IP ranges or loopback addresses regardless of proxy configuration. Regular security audits focusing on SSRF vectors in workflow nodes and API endpoints are essential to prevent similar oversights in future updates.