CVE-2026-105761: 
Dify vulnerability analysis and mitigation

CVE-2026-105761 is an Insecure Direct Object Reference (IDOR) vulnerability in Dify, an open-source LLM application development platform, affecting all versions prior to 1.16.0. The flaw exists in the PUT /console/api/apps/<app_id>/server endpoint (api/controllers/console/app/mcp_server.py), where the AppMCPServerController.put() method retrieves an AppMCPServer record using only the client-supplied server ID without verifying ownership by the requesting application or tenant. It was published on October 5, 2026, and fixed in version 1.16.0. The vulnerability carries a CVSS v3.1 base score of 7.1 (High) (GitHub Advisory).

The root cause is classified as CWE-639 (Authorization Bypass Through User-Controlled Key): the put() handler performs a bare primary-key database lookup (db.session.get(AppMCPServer, payload.id)) using the attacker-controlled id field from the request payload, without scoping the query to the current application (app_model.id) or tenant. In contrast, sibling handlers in the same file (get(), post(), refresh()) all enforce ownership checks. An authenticated workspace member can craft a PUT request to their own application's server endpoint while supplying the server ID of a victim application, successfully modifying that application's MCP server status and parameters. The fix, merged in PR #38177, replaces the bare lookup with a scoped SQLAlchemy query filtering on AppMCPServer.id, AppMCPServer.app_id, and AppMCPServer.tenant_id simultaneously (GitHub Advisory, Fix Commit).

A successful exploit allows any authenticated workspace member — regardless of their role — to modify MCP server configurations belonging to other applications within the same workspace. The attacker can disable a victim application's MCP server (causing a service outage), alter connection parameters to redirect data flows to attacker-controlled endpoints, or inject malicious configuration values without the application owner's knowledge. There is no direct confidentiality impact (CVSS C:N), but integrity is rated High and availability Low, reflecting the ability to corrupt configurations and disrupt services across organizational team boundaries (GitHub Advisory).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported. The NVD SSVC assessment classifies exploitation as "none" at time of publication. The EPSS score is approximately 0.0025 (0.25%), indicating a low probability of near-term exploitation. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires only a valid authenticated session within the target workspace — no elevated privileges are needed — making it accessible to any workspace member (GitHub Advisory, Feedly).

1. Reconnaissance: As an authenticated workspace member, enumerate application IDs visible in the workspace via the Dify console UI or API. Identify the target (victim) application and note its MCP server ID, which may be discoverable through API responses or workspace-level listings.
2. Obtain attacker app context: Use the attacker's own application ID as the <app_id> path parameter in the request URL to pass the outer application-level authorization check.
3. Craft malicious PUT request: Send a PUT /console/api/apps/<attacker_app_id>/server request with a valid authentication token, but supply the victim application's MCP server ID in the request body payload field id.
4. Inject malicious payload: Include desired modifications in the request body, such as setting "status": "inactive" to disable the victim's server, or replacing "parameters" with attacker-controlled values to redirect data flows.
5. Achieve unauthorized modification: The server performs only a primary-key lookup on the supplied id, returns the victim's AppMCPServer object, and commits the attacker's changes — returning HTTP 200 OK with no ownership validation (GitHub Advisory).

• Network/API Logs: PUT /console/api/apps/<app_id>/server requests where the id field in the request body does not correspond to any MCP server belonging to the <app_id> in the URL path — cross-reference server IDs against application ownership records.
• Application Logs: Unexpected changes to AppMCPServer records (status transitions to inactive, parameter overwrites) for applications whose owners did not initiate a change; audit log entries showing MCP server updates attributed to users from a different application context.
• Database: AppMCPServer rows with app_id values that do not match the app_id of the account that last modified them; sudden parameter field changes (e.g., JSON values containing unexpected keys like "injected") in MCP server records.
• Behavioral: MCP-dependent services unexpectedly going offline or routing data to unfamiliar endpoints; application owners reporting configuration changes they did not make.

Upgrade Dify to version 1.16.0 or later, which contains the fix introduced in commit 62cb5b5 via PR #38177. The patch scopes the AppMCPServer database lookup to include AppMCPServer.app_id == app_model.id and AppMCPServer.tenant_id == server_ref.tenant_id, preventing cross-application access. No configuration-based workaround is available for unpatched versions; the only effective mitigation is upgrading. Organizations should also audit recent MCP server configuration changes for unexpected modifications prior to patching (Dify Release 1.16.0, Fix Commit).