CVE-2026-105762

Executive Summary

CVE-2026-105762 is a server-side request forgery (SSRF) vulnerability in Dify, an open-source LLM application development platform. Prior to version 1.13.0, the /console/api/remote-files/upload endpoint in api/controllers/web/remote_files.py accepted an attacker-controlled URL without authentication and caused the Dify server to fetch that URL. A remote, unauthenticated attacker can leverage this to reach internal services and cloud metadata endpoints, potentially exposing sensitive data and turning the Dify server into a network pivot.

Technical Analysis

The vulnerability is classified as CWE-918 (Server-Side Request Forgery) and carries a CVSS 3.1 base score of 8.3 (High). The NVD description states that the /console/api/remote-files/upload endpoint in api/controllers/web/remote_files.py accepted an attacker-controlled URL without authentication and caused the Dify server to retrieve it.

The attack surface consists of any network-reachable Dify instance running a version prior to 1.13.0 that exposes the console API. The core defect is the absence of two independent controls:

1. Authentication/authorization — the endpoint is reachable without credentials (PR:N in the CVSS vector), so no prior foothold is required.
2. URL validation / egress filtering — the server performs an outbound HTTP request to a destination supplied by the caller, without (per the description) restricting the target to safe, external, expected origins. This is the defining characteristic of SSRF.

Because the server, not the attacker, initiates the request, the attacker's network position is irrelevant to reachability — the request originates from the Dify host and therefore inherits its network access, including access to internal (RFC1918/private) ranges and cloud instance metadata services that are normally unreachable from the public internet.

The CVSS vector reflects the SSRF characteristics precisely:

• AV:N — reachable over the network.
• AC:L — no special conditions are required to trigger.
• PR:N — no privileges/authentication required.
• UI:N — no user interaction.
• S:C — scope is Changed: exploitation can affect resources beyond the vulnerable component's security authority (i.e., other internal systems the Dify host can reach), which is the canonical SSRF impact.
• C:L/I:L/A:L — limited confidentiality, integrity, and availability impact, consistent with data exposure via internal requests and use of the host as a pivot rather than direct destruction.

The issue is stated to be fixed in version 1.13.0. No further code-level detail (e.g., specific validation routine) is provided in the source data, and none should be assumed.

Exploitation Scenarios

No public PoC, Nuclei template, or exploit code is available. The attack chain below is inferred strictly from the SSRF vulnerability class and the NVD description.

1. Reconnaissance / target identification. The attacker identifies an internet-exposed Dify instance running a version prior to 1.13.0. Public-facing Dify deployments (commonly identified via HTTP banners/titles and known service ports) are the candidate targets. Fingerprinting is passive/observable only.

2. Triggering the flaw. The attacker sends a request to the /console/api/remote-files/upload endpoint supplying an attacker-controlled URL. Because the endpoint requires no authentication, no credentials or session are needed. The URL points to a destination of the attacker's choosing rather than a legitimate remote file source.

3. Payload / execution method (vulnerability-class level). The Dify server itself performs the outbound retrieval of the attacker-supplied URL. The attacker does not need any special payload beyond crafting the request with the malicious URL; the server's own request is the exploitation mechanism. Typical SSRF target classes for this pattern include:

   • Internal-only HTTP services on the local host or private network segments reachable from the Dify server.
   • Cloud instance metadata endpoints (e.g., link-local metadata services) exposed to the instance, which can yield credentials or configuration data.
   • Internal administrative interfaces not otherwise exposed to the internet. The precise internal targets depend entirely on the Dify host's network position and cloud environment; no endpoints are specified in the source data.

4. Post-exploitation impact. Successful exploitation can expose sensitive data returned from internal services (confidentiality), allow the attacker to use the Dify server as a network pivot to reach otherwise-inaccessible internal resources, and — depending on what the internal endpoints permit — potentially influence state on those services (integrity) or disrupt them (availability). The "Changed" scope reflects impact extending to systems adjacent to Dify.

Note: Because no exploit code exists publicly, any claim of a validated end-to-end chain would be speculative; the above describes the vulnerability class and the mechanism derivable from the description.

Impact Assessment

• Confidentiality (Low): Exposure of data returned from internal services and/or cloud metadata endpoints. Impact is rated Low in the vector, but real-world exposure of metadata-backed credentials can be severe depending on the environment.
• Integrity (Low): Where internal endpoints accept state-changing requests, the attacker may be able to influence them via the server-mediated request.
• Availability (Low): Internal services can be probed/abused; no direct destructive impact is described.
• Scope (Changed): The most significant factor. The vulnerable component (Dify) is used to affect resources outside its own security boundary — internal networks and cloud metadata services. This is why the base score reaches 8.3 despite Low sub-scores.
• Blast radius: Any Dify deployment prior to 1.13.0 that is network-reachable and runs in a network position with access to internal services or metadata endpoints. Because authentication is not required, exposure to automated scanning is high. Dify is widely deployed as an LLM app platform, and such instances frequently sit in cloud environments with metadata services available — increasing the likelihood that SSRF yields credential material.

Detection Guidance

Sigma Rule

title: Dify SSRF via /console/api/remote-files/upload
id: 8f3a1c2e-5b7d-4a91-9c0e-dify105762ssrf
status: experimental
description: Detects unauthenticated requests to the Dify remote-files upload endpoint that supply an attacker-controlled URL, indicating CVE-2026-105762 SSRF attempts.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-105762
author: valtersit.com
date: 2026-01-01
logsource:
  category: webserver
detection:
  selection_endpoint:
    cs-uri-stem|contains: '/console/api/remote-files/upload'
  selection_method:
    cs-method: 'POST'
  condition: selection_endpoint and selection_method
fields:
  - c-ip
  - cs-uri-stem
  - cs-uri-query
falsepositives:
  - Legitimate authenticated file imports from expected external origins
level: high

YARA Rule

rule CVE_2026_105762_Dify_SSRF_Request
{
    meta:
        description = "Detects HTTP request artifacts targeting the Dify remote-files upload endpoint (CVE-2026-105762 SSRF)"
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-105762"
        date = "2026-01-01"
        severity = "high"

    strings:
        $ep   = "/console/api/remote-files/upload" ascii nocase
        $http = "POST" ascii
        $meta = "169.254.169.254" ascii
        $mdns = "metadata.google.internal" ascii nocase
        $loc  = "localhost" ascii nocase
        $rfc  = "127.0.0.1" ascii

    condition:
        $ep and $http and (1 of ($meta, $mdns, $loc, $rfc))
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-105762 Dify SSRF Attempt via /console/api/remote-files/upload"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/console/api/remote-files/upload"; http.request_body; content:"http"; pcre:"/(169\.254\.169\.254|127\.0\.0\.1|localhost|metadata\.google\.internal)/i"; reference:cve,CVE-2026-105762; classtype:web-application-attack; sid:2026105762; rev:1;)

Elastic Detection

sequence by source.ip with maxspan=1m
  [ network where http.request.method == "POST" and url.path == "/console/api/remote-files/upload" ]
  [ network where destination.ip in ("169.254.169.254", "127.0.0.1", "::1") or dns.question.name like~ "metadata*" ]

Splunk SPL Query

index=web sourcetype=access_combined
| search cs_method=POST uri_path="/console/api/remote-files/upload"
| eval ssrf_indicator=if(match(uri_query, "(?i)(169\.254\.169\.254|127\.0\.0\.1|localhost|metadata\.google\.internal|http://") , 1, 0)
| where ssrf_indicator=1
| stats count min(_time) as first_seen max(_time) as last_seen values(uri_query) as urls by src_ip, cs_host
| convert ctime(first_seen) ctime(last_seen)
| sort - count

Wazuh OSSEC Rule

<group name="web,dify,ssrf,">
  <rule id="105762" level="12">
    <decoded_as>web-accesslog</decoded_as>
    <match>/console/api/remote-files/upload</match>
    <regex type="pcre2">(?i)(169\.254\.169\.254|127\.0\.0\.1|localhost|metadata\.google\.internal)</regex>
    <description>CVE-2026-105762: Possible Dify SSRF attempt to internal/metadata endpoint</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>web_attack,ssrf,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 — UNPATCHED (no patch evidence from any tracked source). The NVD description states the issue is fixed in version 1.13.0, but no vendor advisory, release notes, or commit is confirmed as a tracked patch source in the provided data. Validate against the vendor before relying on it.

1. Immediate mitigations (no confirmed patch):

   • Restrict network exposure of the Dify console API; place it behind authentication-aware reverse proxies or VPN and remove it from the public internet where feasible.
   • Apply egress filtering / network segmentation so the Dify host cannot reach cloud metadata services (block link-local 169.254.169.254) or unnecessary internal RFC1918 ranges.
   • Enforce IMDSv2 (session-token-required metadata) in cloud environments to blunt metadata-based theft.
   • Where a WAF is present, block or alert on requests to /console/api/remote-files/upload carrying internal/metadata URLs.
   • Monitor for outbound requests originating from the Dify host to unexpected destinations.

2. Patch / upgrade steps:

   • Upgrade Dify to 1.13.0 or later, per the NVD description stating the fix. Because patch confidence is 0/4, verify the fix against the official Dify repository/release notes before treating the instance as remediated.

3. Long-term hardening:

   • Require authentication on all console API endpoints handling external resources.
   • Implement allowlist-based URL validation and block requests to private, loopback, and link-local address ranges at the application layer (standard SSRF defenses).
   • Adopt least-privilege network policies for application hosts and continuous dependency/version monitoring.

References

• NVD — CVE-2026-105762: https://nvd.nist.gov/vuln/detail/CVE-2026-105762
• CWE-918 (Server-Side Request Forgery): https://cwe.mitre.org/data/definitions/918.html
• Dify project (official repository / release notes for 1.13.0): https://github.com/langgenius/dify
• OWASP SSRF Prevention Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html

No public PoC, exploit code, threat actor campaign, or exploit-in-the-wild evidence was identified in the provided data. EPSS has not yet been scored by FIRST.org. CVE-2026-105762 is not listed in CISA KEV.