Dify CVE-2026-105761

Requires an authenticated account with workspace-member access to the target Dify instance (CVSS PR:L) and reachability of the console API at PUT /console/api/apps/<app_id>/server. The attacker must know or enumerate the numeric/opaque MCP server ID of another application; no special non-default configuration is needed because the vulnerable code path is the standard MCP server management endpoint in versions prior to 1.16.0. Realistic exposure is highest in multi-tenant or multi-team deployments where untrusted or semi-trusted members share a Dify installation; single-user or fully-trusted deployments face little practical risk. Limiting factors: valid workspace credentials are mandatory (not remotely unauthenticated), and the affected endpoint is console-side rather than a public-facing data API.

This is a genuine but moderate-priority access-control flaw (CWE-639, IDOR/BOLA) rather than a high-urgency internet-facing threat. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L, 7.1 High) is internally consistent with the description: exploitation is network-reachable and low-complexity, but critically requires PR:L - a valid authenticated workspace member - which bounds the attacker population to people who already have accounts in the Dify instance. No EPSS score, KEV listing, or public exploit was provided in the intelligence set, so there is no evidence of active or opportunistic exploitation; the only external references are the fix commit, PR #38177, the 1.16.0 release, and advisory GHSA-ccrj-frp2-c945 - all patch/disclosure artifacts, not exploit code. The impact profile (I:H, A:L, C:N) matches a config-tampering bug: an attacker can alter or disable another application's MCP server but the vector does not assert direct data disclosure. One nuance to verify: the description's phrase 'potentially redirecting data' hints at a downstream confidentiality effect that the official C:N rating does not capture, so defenders in sensitive multi-tenant deployments should treat confidentiality exposure as plausible even though it is not in the base score. Overall: a real authorization defect worth patching promptly in shared/multi-tenant Dify instances, but not a drop-everything issue given the authentication prerequisite and absence of exploitation signals.

In a shared Dify workspace, a low-privileged but authenticated member who should only control their own apps obtains or guesses the MCP server ID belonging to a colleague's application and sends a crafted PUT /console/api/apps/<app_id>/server request. Because the vulnerable handler looked up the AppMCPServer purely by the client-supplied ID without checking app/tenant ownership, the attacker can flip the target server's status or rewrite its parameters - disabling the service or redirecting its data flow. No public exploit code was identified, but the low attack complexity (AC:L) and absence of required user interaction make exploitation straightforward for any insider with workspace access.