Dify before 1.13.0 let unauthenticated callers make the server fetch any URL via its remote-files routes. Upgrade, restrict egress, enforce IMDSv2.
Dify versions before 1.13.0 contain a server-side request forgery (SSRF) flaw, CVE-2026-105762, in the console's remote-files endpoints. Self-hosted operators are the ones who must act. The GitHub advisory says unauthenticated users can make the Dify server request arbitrary URLs, including internal services and cloud metadata addresses. It carries a CVSS 3.1 score of 8.3 (High). No source we read reports exploitation in the wild.
What happened
Dify's advisory GHSA-8235-vv5j-mmvg, titled "Unauthenticated Server-Side Request Forgery in /console/api/remote-files/upload endpoint", lists versions before 1.13.0 as affected and 1.13.0 as patched. It credits the reporter Wat4rFlow and was published on 19 May 2026; a maintainer note on 22 June corrected the patched version to 1.13.0. NVD published its record on 6 October 2026 with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:L and CWE-918.
The code fix is older than either record. Pull request #32236 (commit 2f87ecc) was merged on 11 February 2026, and Dify 1.13.0 was published the same day. Its commit message is "fix: fix use fastopenapi lead user is anonymouse", and it was filed against a bug where remote-URL file uploads failed during a workflow test run (issue #32210). The 1.13.0 release notes list the change ("fix: fix use fastopenapi lead user is anonymouse") and describe it as "a FastOpenAPI integration regression where authenticated users could be resolved as anonymous in remote file APIs". They present it as a functional regression, not a security fix. FastOpenAPI registration of these routes appears in 1.12.0; 1.11.4 used Flask-RESTX.
Why it matters
Dify is a platform for building LLM applications, and self-hosted instances usually sit next to model-provider keys, vector stores and internal databases. A server that fetches attacker-chosen URLs from that position can be pointed at services that were never meant to be reachable from outside. (We covered a similar MCP fetch server SSRF, and another self-hosted AI gateway flaw.) The advisory names the AWS/GCP metadata server ("IAM credentials") and network pivoting as the impact, and also mentions denial of service against internal infrastructure.
The base score reflects a network-reachable flaw that needs no privileges and no user interaction, with a changed scope and low impact on confidentiality, integrity and availability.
Technical details
Two points differ from the way the advisory and NVD describe the bug.
The route. The advisory and NVD both name /console/api/remote-files/upload and the file api/controllers/web/remote_files.py. The fix commit does not touch that file. It changes api/controllers/console/remote_files.py, and it covers two routes, not one: POST /remote-files/upload and GET /remote-files/<path:url>. The web controller is a separate route family; in 1.12.1 it derives from WebApiResource, the web-app authentication base class. Treat the console routes as the affected surface and the NVD file path as a probable mislabel. We did not test either endpoint.
What changed. In 1.12.0 and 1.12.1 the console routes were registered through controllers.fastopenapi (console_router) with no login decorator. The fix moves them to Flask-RESTX (console_ns) and adds @login_required to both handlers. In the pre-fix upload handler the outbound HEAD/GET through ssrf_proxy runs before the code looks up the current account, so an anonymous caller would still trigger the outbound request. That ordering is our reading of the code, not a statement from the advisory.
The fetch already went through Dify's ssrf_proxy helper, and the fix keeps it. We did not establish how much that helper (or the SSRF proxy container in the default Docker deployment) blocks in practice, so do not assume it neutralised metadata or private-range requests. The advisory's own mitigation advice names 169.254.169.254, 127.0.0.1 and 10.0.0.0/8, allow and deny lists, DNS-rebinding protection and response timeouts.
"Unauthenticated". The advisory's title and first sentence say "An unauthenticated Server-Side Request Forgery (SSRF) vulnerability exists in Dify". Its Details text, however, mentions a request "with authentication" next to a screenshot, while the proof-of-concept request carries no session or auth header, so we attribute "unauthenticated" to the advisory rather than to our own testing. Version 1.11.4 and earlier also lack @login_required in the console file, but we did not verify whether authentication was applied elsewhere, so the advisory's "before 1.13.0" is the range to use, not a narrower one of our own.
How an unauthenticated request turns Dify into a proxy to internal services.
What defenders should do
- Upgrade. Move to 1.13.0 at minimum. Dify's latest release at the time of writing is 1.17.1 (10 September 2026), and its console upload route keeps
@login_required. Use the current release as your floor. - Restrict egress. Block outbound traffic from the Dify API and worker containers to loopback, link-local (169.254.169.254) and private ranges. The advisory names 169.254.169.254, 127.0.0.1 and 10.0.0.0/8; we would block all RFC 1918 ranges. Add DNS-rebinding protection and response timeouts as the advisory suggests, and allow only the destinations the deployment needs.
- Enforce IMDSv2 on AWS hosts. Require session-token metadata requests, and set the hop limit to 1 so containers cannot reach the metadata service. This limits what a forged request can read; it is general cloud hardening, not a vendor instruction for this CVE. Scope the instance role narrowly.
- If you cannot upgrade yet, block unauthenticated access to
/console/api/remote-files/at the reverse proxy. This is our suggestion, not the advisory's (its "authenticate or restrict access" advice concerns a different endpoint, /ssrf/test), and we have not tested it. - Look back. Search reverse-proxy and API logs for requests to
/console/api/remote-files/from clients with no session, and for outbound requests from the Dify host to metadata or internal addresses. If you find them, rotate the instance role credentials and any secrets reachable from the host.
What is still unclear
- Whether exploitation has occurred. We found no report of it, and the flaw is not listed in CISA's KEV catalog as of 6 October 2026.
- The earliest affected version. The advisory says "prior to 1.13.0"; the regression boundary was not confirmed.
- The exact affected file, given the mismatch between NVD and the fix commit.
- How much the
ssrf_proxylayer limited real-world reach in default deployments. - Whether Dify Cloud was affected. The reporter's proof of concept targets
POST /console/api/remote-files/uploadwithHost: cloud.dify.ai, but Dify has not said whether, or for how long, Cloud was exposed.