Dify CVE-2026-105762

No special conditions beyond network reachability - the pre-1.13.0 /console/api/remote-files/upload (POST) and /remote-files/<path:url> (GET) endpoints accepted an attacker-controlled URL with NO authentication (PR:N confirmed by the added @login_required in the fix), so a remote unauthenticated attacker can trigger the server-side fetch against default configurations. The practical LIMITING factor is Dify's existing ssrf_proxy wrapper, which may filter internal/metadata targets depending on its allowlist configuration; exploitation impact also depends on the instance being network-exposed to the attacker and on internal services/cloud metadata being reachable from the Dify host.

This is a genuine, actionable SSRF (CWE-918) rather than a paper-high score. The provided CVSS:3.1 vector (AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:L, base 8.3) indicates network-reachable, low-complexity, unauthenticated exploitation with a scope change, and the source-code evidence corroborates this directly: the fixing PR (#32236) adds @login_required to the previously anonymous /console/api/remote-files/upload and /remote-files/<path:url> handlers, confirming the pre-1.13.0 endpoints performed server-side fetches of attacker-supplied URLs with no authentication. The scope change (S:C) is well-justified because the server can be coerced into reaching internal-only services and cloud metadata endpoints - a different security authority than the Dify app itself. Countervailing signals temper urgency: no EPSS score, no CISA KEV listing, and no public POC were supplied, so there is no evidence of active exploitation or mass scanning yet. Note also that Dify already routes these requests through an 'ssrf_proxy' helper, meaning the residual risk depends on how robust that proxy's allowlist/deny-internal logic is - the primary defect fixed was the missing authentication gate, not the fetch mechanism itself. Net: prioritize patching to 1.13.0 for internet-exposed Dify instances (unauthenticated + scope change is a classic pivot primitive), but absent EPSS/KEV/POC this is an elevated-not-emergency item.

An attacker who can reach an internet-exposed Dify instance sends an unauthenticated POST to /console/api/remote-files/upload with a URL pointing at an internal service or the cloud metadata endpoint (e.g. 169.254.169.254). The Dify server fetches that URL and returns metadata/content, letting the attacker enumerate internal hosts or harvest cloud instance credentials and use the server as a network pivot. No public exploit identified at time of analysis, though the single-request nature and low complexity (AC:L) make exploitation trivial to script.