CVE-2026-41947

Dify < 1.14.2 Authorization Bypass via Trace Configuration Endpoints

No known exploitation. EPSS puts it in the 47th percentile. Only a workaround so far.

CVSS 3.19.1Critical EPSS percentile47th0.6% chance in 30 days CISA KEVNot listedNo confirmed exploitation
No public exploit known FixWorkaroundNo fixed build yet

Published 2026-05-18Updated 2026-06-22Sources: CVE.org, NVD

NVD CVE.org

What to do

No fixed build is published yet. The vendor describes a workaround.

Steps

Written by AI from the record

Check whether your dify deployment is running a version earlier than 1.14.2.
Identify whether any accounts with “editor” ability exist that are not strictly limited to trusted staff.
Upgrade dify to version 1.14.2 or later.
After upgrading, verify trace settings/trace endpoints are only configured for the intended applications and tenants.

Vendor advisory Usually a quick update

Is your organisation exposed?Request an assessment to establish which checks fit your systems.

What it is

From the CVE record

Dify before version 1.14.2 contains an authorization bypass vulnerability that allows authenticated editor users to set and enable trace configurations for any application regardless of tenant ownership. Attackers can exploit missing tenant ownership checks in the trace configuration endpoints to redirect all messages and responses from victim applications to attacker-controlled LLM trace providers. NOTE: Dify Cloud allows unauthenticated free self-registration, making account creation trivially accessible to any attacker.

In plain language

Written by AI from the record

In Dify versions before 1.14.2, a signed-in editor user can set tracing for other tenants’ applications, potentially redirecting private messages to an attacker-controlled tracing service—small businesses running Dify should patch because multi-tenant setups are especially exposed.

In dify before 1.14.2, there is an authorization bypass (CWE-639) in Trace configuration endpoints that is triggered by missing tenant ownership checks; an authenticated editor user can configure trace endpoints for any application on the instance, enabling message/response redirection to attacker-controlled LLM trace providers.

If you're affected

Cross-tenant private data exposure
Persistent data exfiltration channel
Compromised customer/service prompts
Operational trust and compliance impact

What is it

Think of Dify tracing like a “logging mirror” that can capture what an app processes. This flaw lets a logged-in editor user point that mirror at an attacker-controlled destination for other tenants’ apps, so sensitive messages can be copied out without needing to fully take over the system.

Who is affected

This matters if you run dify (self-hosted or otherwise) in a multi-tenant setup where different customers/teams share the same instance. It also matters if you have any user accounts with editor permissions that aren’t tightly controlled, because exploitation needs an authenticated editor user.

The risk is greatest when that editor account can reach and use the tracing configuration endpoints (and the instance is configured to allow tracing/trace configuration for applications).

How urgent is it

This should be treated as a high-priority fix for businesses running dify because the problem can enable cross-tenant private data exposure via trace endpoint reconfiguration. While there’s no confirmed KEV entry and no public exploit code on record, security researchers have reported the issue and it can be abused by a tenant user who has editor access.

Patch to 1.14.2 promptly to prevent attackers from setting up a persistent exfiltration path through tracing.

What to do — in detail

Confirm exposure

Determine the exact dify version running in your environment.
Verify whether your deployment uses multiple tenants (different customers/teams on the same dify instance).
Check who can access the Dify “editor” role and whether those users are strictly limited to trusted staff.

Upgrade (required fix)

Upgrade dify to 1.14.2 (or later).
If you maintain multiple environments (prod/staging), upgrade production first or in a controlled maintenance window, then repeat for non-production.

Post-upgrade validation

Review trace configuration for applications across tenants:
- Confirm trace endpoints are set only for the intended applications/tenants.
- Ensure there are no unexpected attacker-controlled trace providers configured.
Review recent changes to trace settings (who changed them, when, and from where).

Workarounds if you can’t upgrade immediately

Apply the mitigation approach from the referenced patch discussion if you can’t upgrade right away: https://github.com/langgenius/dify/pull/35793
As a practical safety measure, reduce editor access immediately to only necessary trusted accounts until you can complete the upgrade.

What to monitor

Monitor administrative and configuration audit logs for changes to trace configuration endpoints.
Watch for unusual outbound connections from the dify host to unexpected external tracing/logging destinations.

Timing

CISA KEV listing was not provided for this CVE, so follow your internal patch SLA; given cross-tenant impact, upgrade is strongly recommended as soon as possible.

Technical context

Severity: reported as critical by scoring (CVSS 9.1). The weakness is CWE-639 (authorization bypass). Attack mechanism: missing tenant ownership checks in dify trace configuration endpoints allow an authenticated editor user to configure/enable tracing for any application regardless of tenant ownership.

Impact mechanics: by redirecting trace endpoints, an attacker can capture and exfiltrate message content (messages and responses) from victim applications, potentially creating a persistent exfiltration channel.

Exploitation status: not listed in CISA KEV, and no clear dated exploitation claim was provided in the press findings; however, the issue is described as enabling cross-tenant private data access in multi-tenant configurations when an attacker has an editor-capable account.

Patch status: fixed in dify 1.14.2, with mitigation discussion available at https://github.com/langgenius/dify/pull/35793.

This is a general assessment based on public vulnerability data. It does not account for your specific infrastructure — when in doubt, consult a security specialist.

Exploitation

Where each signal puts this CVE on the scale from published to confirmed exploited.

EPSS47th

CISA KEV

Not in the catalog. CISA has not confirmed exploitation.

Public exploits

No public exploit or proof of concept found in the sources we track.

EPSS

0.6% chance of exploitation activity in the next 30 days, which ranks it in the 47th percentile of scored CVEs.

Exploit Prediction Scoring System, FIRST.org. A probability, not a confirmation.

Lifecycle

5 events over 35 days, from the signal feeds we watch.

2026-06-22Workaround availablerecord updated
2026-05-18Publishedweakness classified, att&ck mapped

Affected products

langgeniusoss-projectaka dify, langgenius/dify
- difyMixedAI / ML / llm-serving-inference
difycommercial
- difySaaSAI / ML / llm-serving-inference

Technical detail

CVSS 3.1 vector

Open in the CVSS calculator

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

Scored 9.1 by NVD.

How it is reached

Attack Vector NetworkExploitable remotely over the network without any special conditions
Attack Complexity LowNo special conditions — the attack can be reliably reproduced
Privileges Required NoneNo authentication required — anyone can exploit this
User Interaction NoneNo user interaction needed — fully automated exploitation

Scope

Scope UnchangedImpact is limited to the vulnerable component itself

Impact if exploited

Confidentiality HighTotal information disclosure — all data in the component is compromised
Integrity HighTotal loss of integrity — attacker can modify any data in the component
Availability NoneNo availability impact