CVE-2026-41947: 
Dify vulnerability analysis and mitigation

CVE-2026-41947 is an authorization bypass vulnerability in Dify, an open-source LLM application development platform, affecting versions up to and including 1.14.1. The flaw allows authenticated editor users to read, modify, or delete trace configurations for any application regardless of tenant ownership, enabling redirection of all application messages and responses to attacker-controlled LLM trace providers. On Dify Cloud, free unauthenticated self-registration makes account creation trivially accessible, effectively lowering the barrier to exploitation. The vulnerability was published on May 18, 2026, and patched in version 1.14.2 released May 19, 2026. It carries a CVSS v3.1 base score of 9.1 (Critical) and a CVSS v4.0 base score of 9.3 (Critical) (GitHub Advisory, Feedly).

The root cause is CWE-639 (Authorization Bypass Through User-Controlled Key): the /console/api/apps/<app_id>/trace-config endpoints (GET, POST, PATCH, DELETE) in api/controllers/console/app/ops_trace.py and the AppTraceApi endpoints in app.py verified authentication but did not validate that the supplied app_id belonged to the caller's tenant. An attacker from Tenant A could supply any app_id from Tenant B and successfully read, overwrite, or delete its tracing configuration. The fix applies the existing @get_app_model decorator to all affected verbs, which loads the App record filtered by App.tenant_id == current_tenant_id and raises a 404 AppNotFoundError on mismatch — the same pattern already used in mcp_server.py and workflow_trigger.py (GitHub PR #35793, GitHub Advisory).

Successful exploitation allows an attacker to redirect all prompts, messages, and LLM responses from any victim application to an attacker-controlled tracing provider (e.g., a malicious Langfuse or OpenTelemetry endpoint), resulting in full interception of sensitive application data and communications. Both confidentiality (exfiltration of all conversation content) and integrity (unauthorized modification or deletion of trace configurations) are severely impacted, while availability is not directly affected. In multi-tenant Dify Cloud deployments, a single free account can be used to target applications belonging to any other tenant, making the blast radius organization-wide (GitHub Advisory, Feedly).

A proof-of-concept has been submitted via the Huntr bug bounty platform, though the page content was not publicly accessible at time of analysis (Huntr PoC). There is no confirmed evidence of in-the-wild exploitation as of the report date. On Dify Cloud, the effective privilege requirement is none, since free self-registration is open to anyone, making the attack fully unauthenticated in practice. The EPSS score is approximately 0.028–0.038% (12th percentile), indicating low but non-negligible exploitation probability in the near term. No CISA KEV catalog listing has been identified (GitHub Advisory, Feedly).

1. Account Registration: On Dify Cloud, register a free account without any special privileges. For self-hosted instances, obtain or create any editor-level account.
2. Enumerate Target App IDs: Use the Dify console API (e.g., GET /console/api/apps) with the attacker's own tenant credentials to understand the API structure. App IDs are UUIDs that may be discoverable through other means (e.g., shared links, API responses, or brute force).
3. Probe Cross-Tenant Endpoints: Send a GET request to /console/api/apps/<victim_app_id>/trace-config?tracing_provider=langfuse using the attacker's session token, substituting a target app ID from another tenant. In unpatched versions, the server returns the trace configuration without a tenant ownership check.
4. Inject Malicious Trace Provider: Send a POST or PATCH request to /console/api/apps/<victim_app_id>/trace-config with a payload specifying an attacker-controlled Langfuse or OpenTelemetry endpoint as the tracing provider and setting enabled: true.
5. Intercept Application Data: Once the malicious trace configuration is active, all prompts, LLM responses, and conversation data from the victim application are forwarded to the attacker-controlled endpoint, enabling passive interception of all traffic (GitHub PR #35793, GitHub Advisory).

• Network: Outbound HTTPS connections from the Dify API server to unexpected external endpoints (e.g., non-organizational Langfuse instances, unknown OpenTelemetry collectors) originating from the tracing subsystem.
• Logs: API access logs showing authenticated requests to /console/api/apps/<app_id>/trace-config or /console/api/apps/<app_id>/trace where the requesting account's tenant does not match the app's tenant; repeated cross-tenant POST/PATCH requests to trace-config endpoints from a single account.
• Application State: Trace configurations on applications unexpectedly changed to point to external or unknown providers; enabled flag set to true on trace configs that were previously disabled or unconfigured.
• Account Activity: New accounts created on Dify Cloud shortly before anomalous trace configuration changes; editor-role accounts accessing trace endpoints for apps outside their workspace (GitHub PR #35793).

The primary remediation is to upgrade Dify to version 1.14.2 or later, which enforces tenant scoping on all trace configuration endpoints via the @get_app_model decorator (Dify v1.14.2 Release, GitHub PR #35793). For self-hosted deployments, follow the upgrade guide: pull the 1.14.2 tag, run flask db upgrade, and restart all services. If immediate patching is not possible, consider disabling trace/observability functionality entirely or restricting network access to the console API to trusted IP ranges. On Dify Cloud, no user action is required as the platform is managed by the vendor.

The vulnerability was reported by researcher zafido via the Huntr bug bounty platform and coordinated through a private GitHub Security Advisory (GHSA-48xc-wmw8-3jr3). Community contributor xr843 submitted the fix PR independently before the official patch, which was acknowledged and merged by Dify maintainers. The fix was bundled into the v1.14.2 patch release alongside other tenant-scoping security fixes. Coverage appeared on security aggregators including VulnCheck, Infinitsec, and ENISA's EUVD shortly after disclosure (GitHub PR #35793, VulnCheck Advisory).