Four critical vulnerabilities in Dify’s cloud platform — collectively dubbed DifyTap by researchers at Zafran — allow attackers to read private AI conversations, access uploaded documents, and make unauthorized API calls belonging to other customers. With over one million AI applications running on Dify across more than 50 industries, the exposure is substantial.
What DifyTap Is and How It Was Found
Security firm Zafran identified the vulnerability cluster during a review of Dify’s multi-tenant cloud infrastructure. Dify is a widely used platform for building and deploying AI-powered applications, and its architecture serves diverse customers — from individual developers to enterprise organizations — in a shared environment. That shared environment is exactly where DifyTap’s four CVEs take effect.
Zafran assigned the cluster a collective name to reflect the interconnected nature of the flaws, each of which targets a different layer of tenant isolation within the platform.
The Four CVEs and Their Severity
The most severe flaw in the group, CVE-2026-41948, carries a CVSS score of 9.4. It resides in Dify’s plugin daemon and allows an attacker to issue arbitrary GET and POST requests to internal API endpoints, including through path traversal techniques. In practical terms, this means a malicious actor could reach internal services that are not intended to be externally accessible.
CVE-2026-41948 (CVSS 9.4): Plugin Daemon Path Traversal and Cross-Tenant API Access
CVE-2026-41947, scored at 9.1, targets the platform’s tracing functionality. The tracing system fails to validate which tenant is making a configuration request, so an attacker can configure tracing on any application they can reach — not just their own. This creates an avenue for monitoring or manipulating the operational data of other customers’ AI applications.
CVE-2026-41949 and CVE-2026-41950: File Handling Flaws Enabling Cross-Tenant Document Access
CVE-2026-41949 and CVE-2026-41950 address file handling. Flaws in file identification logic and permission enforcement allow a tenant to preview and download files uploaded by other tenants. In an AI application context, those files may include proprietary documents, training data, or sensitive user submissions.
Cross-Tenant Data Accessible to Attackers
Taken together, the four vulnerabilities enable a malicious Dify customer to read private AI chat histories from other tenants’ applications, retrieve files those tenants have uploaded to the platform, and initiate cross-tenant internal API calls. Each of those actions crosses a fundamental boundary in multi-tenant cloud security — the guarantee that one customer’s data and operations remain invisible and inaccessible to another.
Zafran’s research also surfaced a separate, longer-standing issue: Dify had been shipping a vulnerable build of the PDFium library (CVE-2024-5846, a use-after-free flaw) for roughly 18 months before it was updated in December 2025.
Timeline and Patch Status
Dify addressed all four DifyTap vulnerabilities in version 1.14.2 of the platform. Organizations running self-hosted Dify deployments should verify they have upgraded to at least this version. Customers on Dify’s managed cloud should confirm with the vendor whether their environments have received the patch.
The December 2025 PDFium update resolved CVE-2024-5846 separately. The 18-month exposure window for that flaw predates the DifyTap disclosure and represents an independent risk vector that was present during a period when Dify was growing rapidly across enterprise sectors.
Impact and Industry Takeaway
For organizations that have integrated Dify into customer-facing or internally deployed AI workflows, DifyTap represents a breach scenario with high data sensitivity. Private AI conversations can contain personally identifiable information, confidential business data, or regulated content depending on how the application is built. Unauthorized internal API calls could extend the blast radius beyond data exposure into active interference with platform operations.
The disclosure reinforces a structural concern with multi-tenant AI infrastructure: as AI application platforms scale to serve millions of deployments, the attack surface for tenant-isolation failures scales with them. A single vulnerability in a shared component can affect every customer on the platform simultaneously. Vendors operating at this scale face compounding pressure to treat tenant boundary enforcement as a first-class security requirement rather than an assumed property of their architecture.
