CVE-2026-105761 in Dify
Summary
by MITRE • 10/06/2026
Dify is an open-source LLM app development platform. Prior to 1.16.0, the PUT /console/api/apps/<app_id>/server endpoint in api/controllers/console/app/mcp_server.py used AppMCPServerController.put() to retrieve an AppMCPServer by the client-supplied server ID without verifying that the server belonged to the requested application and tenant. An authenticated workspace member could therefore change another application's MCP server status and parameters, potentially redirecting data or disabling the service. This issue is fixed in version 1.16.0.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/06/2026
The vulnerability identified in Dify prior to version 1.16.0 represents a critical failure in access control mechanisms within its API infrastructure. Specifically, the PUT /console/api/apps/<app_id>/server endpoint, implemented via the AppMCPServerController.put() method, suffered from an insecure direct object reference flaw. In this context, the application accepted a server identifier provided by the client to locate and modify an MCP (Model Context Protocol) server configuration but failed to validate that this server ID was legitimately associated with the specific application identified in the URL path or the authenticated tenant's workspace. This architectural oversight created a scenario where the integrity of resource ownership checks was compromised, allowing for unauthorized manipulation of system configurations.
From a technical perspective, the core issue lies in the absence of proper authorization logic during state-changing operations. When an authenticated user sends a request to update server parameters or status, the backend processes the client-supplied ID without cross-referencing it against the access control lists tied to the requesting application and tenant. This lack of verification means that any valid workspace member can target arbitrary resources within the broader system scope rather than being restricted to their own designated assets. The flaw effectively bypasses the intended isolation boundaries between different applications and tenants, treating resource identifiers as public or globally accessible entities subject to modification by anyone with basic authentication credentials.
The operational impact of this vulnerability is significant for multi-tenant environments where data confidentiality and service availability are paramount. An attacker exploiting this flaw could alter the configuration parameters of an MCP server belonging to another application, potentially redirecting API calls to malicious endpoints controlled by the adversary. This capability facilitates unauthorized data exfiltration or interception as sensitive information processed through these servers is rerouted. Furthermore, the ability to change the status of a remote service allows for denial-of-service conditions against other applications within the same tenant workspace, disrupting business operations and degrading system reliability without requiring elevated privileges or additional authentication steps beyond initial login.
This vulnerability aligns with CWE-284, which describes Improper Access Control, specifically highlighting failures in verifying that an actor is authorized to perform a requested action on a specific object. In terms of offensive security frameworks such as MITRE ATT&CK, this behavior corresponds to techniques involving resource hijacking and potential data exfiltration through compromised service configurations. The exploitation path leverages existing valid credentials, making it particularly dangerous for organizations relying on role-based access controls that assume strict scoping of API endpoints per user or application context.
To mitigate the risks associated with this vulnerability, immediate upgrade to Dify version 1.16.0 is required as it contains the necessary patches to enforce proper ownership verification. For environments where upgrading is not immediately feasible, implementing a reverse proxy or Web Application Firewall rule can help by strictly validating that the server ID in the request body matches the app_id parameter in the URL path and ensuring both belong to the same authenticated tenant before forwarding requests to the backend. Additionally, auditing API logs for unusual patterns of cross-application resource modifications can aid in detecting potential exploitation attempts while security teams work toward permanent remediation through code-level fixes that enforce strict object ownership checks on all state-changing endpoints.