Summary
Dify contains an insecure direct object reference in the MCP server management endpoint, allowing an authenticated workspace member to act on a server identified by a client-supplied ID without confirming its application and tenant ownership. Under deployments where a member can reach this endpoint and obtain or guess another server ID, the issue may allow unauthorized parameter changes, data redirection, or service disruption.
Dify contains an insecure direct object reference in the MCP server management endpoint, allowing an authenticated workspace member to act on a server identified by a client-supplied ID without confirming its application and tenant ownership. Under deployments where a member can reach this endpoint and obtain or guess another server ID, the issue may allow unauthorized parameter changes, data redirection, or service disruption.
Affected context
The issue occurs in Dify's console API for MCP server management when the requested application identifier and client-supplied server identifier are processed without an effective ownership check. It is relevant to deployments where authenticated workspace members can access the endpoint and MCP server records are not consistently scoped to both the requested application and tenant.
The issue occurs in Dify's console API for MCP server management when the requested application identifier and client-supplied server identifier are processed without an effective ownership check. It is relevant to deployments where authenticated workspace members can access the endpoint and MCP server records are not consistently scoped to both the requested application and tenant.
Exploit preconditions
- Attack surface: Authenticated Dify console API endpoint for MCP server management
- Required access: Valid workspace-member authentication and permission to reach the endpoint
- Trigger point: A request that updates MCP server status or parameters using a server identifier
- Why exploitation is possible: The server record lookup does not sufficiently verify that the selected server belongs to the requested application and tenant
- Attack surface: Authenticated Dify console API endpoint for MCP server management
- Required access: Valid workspace-member authentication and permission to reach the endpoint
- Trigger point: A request that updates MCP server status or parameters using a server identifier
- Why exploitation is possible: The server record lookup does not sufficiently verify that the selected server belongs to the requested application and tenant
Why this happens
The underlying bug is an object-level authorization failure, mapped to CWE-639: Authorization Bypass Through User-Controlled Key. The endpoint trusts a client-supplied object identifier when retrieving an MCP server but does not enforce the complete relationship between that server, the requested application, and the authenticated tenant. This insecure pattern permits an otherwise authorized user to operate on an object outside the intended authorization scope.
The underlying bug is an object-level authorization failure, mapped to CWE-639: Authorization Bypass Through User-Controlled Key. The endpoint trusts a client-supplied object identifier when retrieving an MCP server but does not enforce the complete relationship between that server, the requested application, and the authenticated tenant. This insecure pattern permits an otherwise authorized user to operate on an object outside the intended authorization scope.
Potential impact
- An attacker may change another application's MCP server status
- An attacker may alter MCP server parameters or routing behavior
- Sensitive data could be redirected to an unintended service
- MCP-backed functionality could be disabled or disrupted
- Affected applications or tenants could experience integrity and availability impacts
- An attacker may change another application's MCP server status
- An attacker may alter MCP server parameters or routing behavior
- Sensitive data could be redirected to an unintended service
- MCP-backed functionality could be disabled or disrupted
- Affected applications or tenants could experience integrity and availability impacts
General mitigation guidance
Mitigation generally focuses on enforcing object-level authorization at the point where records are retrieved and modified.
Common defensive patterns include:
- Scope every MCP server lookup to the authenticated tenant and requested application
- Verify resource ownership and relationship authorization before reading or updating objects
- Prefer server-side identifiers and authorization context over unchecked client-supplied relationships
- Apply deny-by-default permissions and least privilege for workspace roles
- Use centralized authorization policies consistently across console API endpoints
- Add immutable or strongly validated tenant and application associations where appropriate
Mitigation generally focuses on enforcing object-level authorization at the point where records are retrieved and modified.
Common defensive patterns include:
- Scope every MCP server lookup to the authenticated tenant and requested application
- Verify resource ownership and relationship authorization before reading or updating objects
- Prefer server-side identifiers and authorization context over unchecked client-supplied relationships
- Apply deny-by-default permissions and least privilege for workspace roles
- Use centralized authorization policies consistently across console API endpoints
- Add immutable or strongly validated tenant and application associations where appropriate
How teams detect issues like this
Organizations can look for this class of issue through:
- Static analysis and code review rules targeting database lookups based only on client-controlled identifiers
- Review signals where update handlers accept both a parent resource ID and child object ID without an explicit relationship check
- Authorization tests that attempt cross-application and cross-tenant object access using authenticated low-privilege accounts
- API gateway or application policy checks requiring tenant and resource ownership constraints
- Audit log analysis for unusual changes to MCP server status, parameters, or application associations
Automated security review tools may help identify missing object-level authorization checks, but business-relationship validation still requires application-specific testing.
Organizations can look for this class of issue through:
- Static analysis and code review rules targeting database lookups based only on client-controlled identifiers
- Review signals where update handlers accept both a parent resource ID and child object ID without an explicit relationship check
- Authorization tests that attempt cross-application and cross-tenant object access using authenticated low-privilege accounts
- API gateway or application policy checks requiring tenant and resource ownership constraints
- Audit log analysis for unusual changes to MCP server status, parameters, or application associations
Automated security review tools may help identify missing object-level authorization checks, but business-relationship validation still requires application-specific testing.
