CVE-2026-6617
Server-Side Request Forgery in langgenius dify ApiToolManageService
Publication date: 2026-04-20
Last updated on: 2026-04-29
Assigner: VulDB
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| langgenius | dify | to 0.6.9 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-918 | The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability exists in the langgenius dify software up to version 0.6.9, specifically in the function get_api_tool_provider_remote_schema within the file api/services/tools/api_tools_manage_service.py of the ApiToolManageService component.
The issue arises when an attacker manipulates the argument 'url' passed to this function, which leads to a server-side request forgery (SSRF). This means the attacker can make the server send unauthorized requests to other internal or external resources.
The attack can be initiated remotely, and the exploit is publicly available.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability allows attackers to perform server-side request forgery (SSRF), enabling them to access internal network resources and sensitive cloud metadata. This can lead to unauthorized access to sensitive information and internal services.
Such unauthorized access and potential data exposure can negatively impact compliance with common standards and regulations like GDPR and HIPAA, which require protection of personal and sensitive data against unauthorized access and breaches.
By enabling network reconnaissance and access to internal APIs, this vulnerability increases the risk of data leakage or compromise, which could result in violations of data protection requirements mandated by these regulations.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by attempting to exploit the SSRF in the get_api_tool_provider_remote_schema method by sending crafted HTTP GET requests to internal or sensitive URLs through the vulnerable API endpoint.
A practical detection approach involves authenticating to the API to obtain valid tokens, then sending requests to the endpoint /console/api/workspaces/current/tool-provider/api/remote with internal URLs as query parameters.
Responses from the server will differ depending on whether the internal ports or services are accessible, which can be used to confirm the presence of the vulnerability and perform network reconnaissance.
- Authenticate to the API to get access tokens.
- Send HTTP GET requests to the vulnerable endpoint with internal URLs, for example using curl:
- curl -H "Authorization: Bearer <token>" "http://<target-server>/console/api/workspaces/current/tool-provider/api/remote?url=http://169.254.169.254/latest/meta-data/"
- Analyze the response to see if internal metadata or service information is returned.
- Use scripts like the provided proof of concept (real_poc_ssrf.py) to automate testing and detection.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include restricting access to the vulnerable API endpoint to trusted users only, as the vulnerability requires authentication but can be exploited by low-privileged users.
Additionally, network-level controls should be applied to prevent the server from making arbitrary HTTP requests to internal or sensitive IP addresses, such as cloud metadata services.
If possible, update or patch the langgenius dify package to a version that fixes the SSRF vulnerability or apply code changes to ensure that all external HTTP requests are routed through the internal ssrf_proxy protection mechanism.
- Restrict API access to trusted and necessary users only.
- Implement network egress filtering to block requests to internal IP ranges and cloud metadata IPs (e.g., 169.254.169.254).
- Patch or upgrade the langgenius dify package to a fixed version when available.
- Modify the vulnerable code to route HTTP requests through the internal ssrf_proxy to enforce URL validation and restrictions.
How can this vulnerability impact me? :
This vulnerability can allow an attacker to make the affected server perform unauthorized requests to internal or external systems, potentially exposing sensitive information or accessing internal services that are not meant to be publicly reachable.
Because the attack can be initiated remotely and the exploit is public, it increases the risk of exploitation.
The impact includes potential information disclosure, unauthorized access, and possibly further attacks leveraging the SSRF to pivot into internal networks.