Dify AI Platform Carried Multi-Tenant Flaws Exposing Private Chats and Internal APIs

Key points

• Authenticated attackers on Dify's shared cloud service could read private chat histories belonging to other tenants.
• The flaws also exposed document previews and internal API endpoints that should be unreachable across tenant boundaries.
• No CVE identifiers had been publicly assigned at time of writing, and Dify had not published a formal advisory with patched-version strings.
• Self-hosted Dify operators should monitor the project's release channel; remediation of the cloud-hosted version sits with the vendor.
• Organizations feeding sensitive material into Dify should audit what their applications send to the platform.

What did attackers actually get access to?

Dify, the AI application framework said to underpin roughly one million deployed apps, carried multi-tenant isolation failures serious enough to expose private conversation data across tenant boundaries. An authenticated attacker on the shared cloud service could read other tenants' chat histories, preview documents those tenants had uploaded, and reach internal API endpoints that peer tenants should never touch. Each primitive is bad on its own; together they describe a real lateral-movement surface inside shared AI infrastructure.

Conversation logs in AI platforms tend to accumulate credentials, personal data, and proprietary business logic that users feed into prompts without much thought for who else sits on the same host. Multi-tenant isolation isn't a nice-to-have; it's the contract the platform makes with every customer on it.

This is the second Dify vulnerability story we've covered in as many weeks. On 22 June we reported on four unauthenticated bugs found by Zafran that let attackers read other tenants' chats without logging in. The flaws reported now required authentication, which narrows the attacker pool but doesn't make them acceptable.

Should you worry if you're running Dify yourself?

Self-hosted deployments face a different risk profile than the cloud tier. Isolation failures that rely on shared infrastructure don't automatically translate to a single-tenant install, but the absence of a formal advisory means defenders can't yet confirm which attack paths apply where. Watch the project's official release channel for patch notices. Don't wait for a CVE.

What's missing from the public disclosure?

No CVE identifiers had been assigned publicly at the time of writing, and the researcher or team behind the discovery hadn't been named in available disclosure materials. Both gaps limit independent verification of scope and severity. Dify's silence on patched-version strings is the more operationally significant problem: without them, there's no clean way to confirm whether a given deployment is fixed.

What should Dify users do now?

Audit what your applications are feeding into the platform. If conversation logs or document uploads contain sensitive material, that data was potentially reachable by co-tenants during the window these flaws were present. The cloud-hosted remediation timeline belongs to Dify; you control what goes in.

The pattern here is worth watching. Two sets of cross-tenant flaws in Dify within a month suggests the isolation model deserves a harder look from the project's security team, not just point fixes.