CVE-2026-41949: Dify Authorization Bypass Vulnerability

CVE-2026-41949 Overview

CVE-2026-41949 is an authorization bypass vulnerability affecting Dify version 1.14.1 and prior. The flaw resides in the /console/api/files/{file_id}/preview endpoint, which fails to verify ownership or workspace membership before returning file content. Any authenticated user can read up to 3,000 characters of any uploaded document across all tenants and workspaces using only the file's Universally Unique Identifier (UUID). On Dify Cloud, free self-registration is open, so any attacker can obtain valid credentials and exploit the endpoint. The issue is tracked under [CWE-639] Authorization Bypass Through User-Controlled Key.

Critical Impact

Authenticated attackers can read sensitive content from documents belonging to any tenant or workspace by supplying intercepted or guessed file UUIDs.

Affected Products

• Dify versions 1.14.1 and earlier
• Dify Cloud (multi-tenant SaaS deployment)
• Self-hosted Dify deployments using the affected console API

Discovery Timeline

• 2026-05-18 - CVE-2026-41949 published to the National Vulnerability Database (NVD)
• 2026-05-19 - Last updated in NVD database

Technical Details for CVE-2026-41949

Vulnerability Analysis

Dify is an open-source platform for building large language model (LLM) applications. The console API exposes a file preview endpoint at /console/api/files/{file_id}/preview intended to render uploaded documents within the user's workspace. The endpoint authenticates the caller but does not authorize the request against the file's owning tenant or workspace. As a result, any logged-in user can pass an arbitrary file UUID and receive back the first 3,000 characters of the underlying document.

The impact is amplified on Dify Cloud, which permits unauthenticated self-registration. An attacker registers a free account, obtains a valid session, and immediately gains the ability to query the endpoint across the entire multi-tenant environment. Documents uploaded for retrieval-augmented generation (RAG) pipelines often contain proprietary source code, internal documentation, customer records, and credentials, all of which become readable through this endpoint.

Root Cause

The root cause is missing authorization logic in the file preview handler. The endpoint resolves the file by its UUID primary key without joining against the requesting user's tenant or workspace context. This is a textbook Insecure Direct Object Reference (IDOR) pattern classified as [CWE-639]. The UUID is treated as a capability token, but UUIDs are not designed to be unguessable secrets and frequently leak through logs, referrer headers, and shared links.

Attack Vector

An attacker obtains a valid Dify account through self-registration on Dify Cloud or any accessible self-hosted instance. The attacker then enumerates or intercepts file UUIDs through shared links, browser history, referer leakage, or by harvesting UUIDs from collaborators. With a valid UUID in hand, the attacker issues a GET request to /console/api/files/{file_id}/preview using their own session token. The server returns up to 3,000 characters of file content regardless of which tenant uploaded the document. No elevated privileges, user interaction, or social engineering is required.

No public proof-of-concept exploit code is available. See the VulnCheck Security Advisory and Huntr Bounty Report for additional technical context.

Detection Methods for CVE-2026-41949

Indicators of Compromise

• High request volume from a single authenticated session to /console/api/files/*/preview with varying file_id UUIDs
• Requests to the preview endpoint where the file_id does not correspond to any file owned by the requesting user's tenant
• Newly registered Dify Cloud accounts issuing preview requests within minutes of signup
• Sequential or randomized UUID enumeration patterns in application access logs

Detection Strategies

• Audit reverse proxy and application logs for cross-tenant access patterns on the /console/api/files/{file_id}/preview route
• Correlate the authenticated user_id and tenant_id against the resolved file's owning tenant for each preview request
• Alert when a single account previews files belonging to more than one tenant within a short window
• Flag accounts that register and immediately begin querying file preview endpoints

Monitoring Recommendations

• Forward Dify console API logs to a centralized logging or Security Information and Event Management (SIEM) platform for retention and analysis
• Build dashboards tracking preview endpoint request rates per account and per source IP
• Monitor for anomalous spikes in 200 responses from the preview endpoint following account creation events

How to Mitigate CVE-2026-41949

Immediate Actions Required

• Upgrade Dify to a version later than 1.14.1 that includes the fix from GitHub Pull Request #35797
• Restrict access to the /console/api/files/{file_id}/preview endpoint at the network or reverse proxy layer until patches are applied
• Review historical access logs for evidence of cross-tenant preview requests and notify affected tenants if exposure is confirmed
• Disable open self-registration on production Dify instances where multi-tenant isolation matters

Patch Information

The maintainers addressed the vulnerability in GitHub Pull Request #35797, which adds tenant and workspace authorization checks to the file preview handler. Operators of self-hosted Dify deployments should upgrade to the patched release. Dify Cloud customers receive the fix automatically through the managed service.

Workarounds

• Place the Dify console API behind a reverse proxy that enforces additional access control on the /console/api/files/*/preview path
• Rotate any secrets, API keys, or credentials that may have been included in uploaded knowledge base documents
• Re-upload sensitive documents with new UUIDs after patching to invalidate any UUIDs that may have leaked

# Example NGINX block restricting the preview endpoint to internal networks until patched
location ~ ^/console/api/files/[^/]+/preview$ {
    allow 10.0.0.0/8;
    deny all;
    proxy_pass http://dify_backend;
}