Dify < 1.15.0 SSRF Protection Bypass via Remote-Files Endpoints
Affects Dify from 0.6.0 before 1.15.0 when the Squid proxy has only source ACLs and make_request() performs no destination IP checks. Fixed in 1.15.0.
Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.
- Exploited
- No known exploitation
- Fix
- Fixed in 1.15.0
- Who is exposed
- Specific setups only
Do first: Check whether your setup matches what the bug needs. Dify versions before 1.15.0 (affecting dify >= 0.6.0, < 1.15.0). Squid proxy configuration only defines source ACLs without destination deny rules, and make_request() performs no independent destination IP validation.
- Last modified
- A 0-100 score for how much a CVE matters across the industry: exploitation, exposure, how widely the software is used, severity and whether a fix exists.What do these mean? →
- 22/100 · provisional
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Specific setups only
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: yes
- Technical impact: partial
Summary
Dify, an open-source platform for building AI applications, is affected by a server-side request forgery flaw that lets a remote attacker with a low-privilege console login send arbitrary HTTP requests from the server to internal services and cloud metadata endpoints, which can expose internal components such as the sandbox, internal APIs, PostgreSQL, and on AWS, instance IAM credentials. The bug is reached remotely through console endpoints such as the remote-files and HTTP Request workflow features, and the HTTP Request node can also send POST, PUT, and DELETE writes to internal services.
Read the original 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.
cve.now Index
- Exploitation0/40No signal
- Exposure15/25Specific setups only, CISA rates it automatable
- Reach?/20Unknown. No tracked technology or package matched
- Severity7.2/10CVSS 7.2
- No patch0/5No signal
What would change the score
- Would score about 72 if added to CISA KEV
- Would score about 67 if CISA's SSVC rates exploitation active
What to do
Check whether your setup matches what the bug needs.
Dify versions before 1.15.0 (affecting dify >= 0.6.0, < 1.15.0). Squid proxy configuration only defines source ACLs without destination deny rules, and make_request() performs no independent destination IP validation.Upgrade to a fixed version: 1.15.0.
Timeline
- CVE published
- First seen by cve.now
- CISA SSVC assessment
Exploitation: none · Automatable: yes · Technical impact: partial
- Record last updated
Affected versions
- langgenius dify
From 0.6.0 · fixed in 1.15.0
Evidence 4
- Patch
- Patch
- Repository
- Link
Corrections
None so far.
Something wrong on this page? Report an error. Every fix is listed here.
Questions about CVE-2026-58141
Is CVE-2026-58141 being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data
What does this mean?
The remote-files endpoints let an authenticated console user send arbitrary HTTP requests that bypass Dify's SSRF protection. Requests can reach internal services and cloud metadata endpoints, including the instance metadata service that holds AWS IAM credentials.Source: vulncheck.com
Which versions are affected by CVE-2026-58141?
dify: from 0.6.0 before 1.15.0.Source: cve.now feed data
Am I affected, and how do I check?
Dify versions from 0.6.0 up to but not including 1.15.0 fall in the affected range. The bypass depends on a setup where the Squid proxy configuration defines only source ACLs without destination deny rules, and make_request() performs no independent destination IP validation. To check, look at the Dify version in the deployment and the Squid ACL configuration.Source: vulncheck.com
How do I fix CVE-2026-58141?
Upgrade Dify to 1.15.0 or later, which is the fixed version.Source: vulncheck.com