Zafran published a family of related data paths in the Dify multi-tenant AI application platform under the name DifyTap on 2026-06-22. The findings combine unauthenticated exposure of AI conversation data, access paths through the Plugin Daemon's internal APIs, cross-tenant risk in the document-preview path, and a parser issue reachable through PDF preview. Zafran's framing is that these are several surfaces rather than one exploit chain: prompt and response history, traces, file UUIDs, tenant identifiers and plugin objects were reachable because authorization was bound at login rather than at each data transition. Dify shipped a fix in release 1.15.0. The AIDEFEND brief's conclusion is that patching closes the reported routes but the architectural properties — object-level authorization, tenant-state isolation, telemetry redaction and sandboxed document handling — are what prevent the next equivalent path.
ASSESSED SYSTEM
The Dify multi-tenant AI application platform as it stood before release 1.15.0 — specifically the Dify API, the Plugin Daemon's internal endpoints, the conversation/trace data stores, and the document-preview (PDF) handlers — in the configuration Zafran examined and published as DifyTap on 2026-06-22.
OUT OF SCOPE
Dify 1.15.0 and later (the vendor shipped a fix). The tenant-built AI applications running on the platform, their models, prompts and knowledge bases, are out of scope except where their conversation, trace and file state was the data exposed. Zafran's own tooling and any downstream victim organisation are out of scope. This assessment scores a point-in-time platform configuration from public research, not Dify as a project or vendor.
Architecture: Tool-Calling LLM / Connected GenAI (decision tree Q3) — Q1 and Q2 are answered NO on the published evidence: the research does not document an inter-agent topology or an autonomous planning loop in the assessed data paths. Q3 is YES — Dify runs a dedicated Plugin Daemon that executes plugin/tool calls on behalf of tenant applications, and the top-priority defence for this case (AID-H-034.003) is server-side tool-invocation validation, which presupposes a tool-calling dispatcher. Trace records containing 'retrieved context' and 'tool arguments' further confirm connector/tool execution and a retrieval layer. Noted for the reader: Dify also ships agent-workflow capability, so individual tenant deployments may classify Agentic under Q2; the surfaces assessed here are the platform's data and plugin plumbing, and the public evidence does not establish an autonomous planning loop in them. Tier 2: Tier 2 Consumer — Dify is an internet-facing multi-tenant platform hosting public-facing AI applications (Zafran describes it as powering 1M+ apps), and the exposure directly affects individual end users' private conversations, uploaded files and any credentials embedded in them; there is no evidence of immediate physical, financial or societal harm at scale that would make it Tier 1.
Documented attack or failure path
- Reach a Dify surface that returns AI conversation or trace data without binding the caller's tenant and session to the target object — at least one route was reachable unauthenticated.
- Read prompt and response history, which Zafran notes can contain credentials, customer data, internal reasoning or operational instructions.
- Pivot through the Plugin Daemon's internal APIs, which bridge trust zones and can become cross-tenant access paths where caller, tenant, session and object authorization are not bound together.
- Enumerate file UUIDs and reach the document-preview endpoint to retrieve another tenant's documents.
- Supply a malformed document to the PDF preview path, where uploaded files cross into parser and rendering components without sandboxing, to reach parser memory corruption.
Observed controls and bounded outcomes
Positive credit is given only where the record directly demonstrates a control operating. Recommended or merely presumed controls receive no positive scoring credit.
- Dify shipped a deterministic fix: release 1.15.0 closes the reported DifyTap routes, and the remediation guidance is a version upgrade plus fleet readback rather than an architectural rewrite.
- The platform's primary product surface is login-gated; Zafran's systemic finding is that authorization was bound at login rather than at each data transition, not that authentication was absent everywhere (one route was reachable unauthenticated).
- Observability was rich rather than absent: the trace subsystem captured prompts, outputs, retrieved context and tool arguments, which is exactly the field coverage needed to investigate — the defect was that those records were not tenant-access-controlled or redacted.
- The research was coordinated: Zafran published with a named fixed release, and the brief's closure control (AID-E-004) can replay every documented route against the fixed population.
Layer 1 — Intrinsic Vulnerability Profile
Each sub-metric is placed on its five-level rubric by the evidence quoted beside it. Missing applicable evidence remains unknown. The displayed midpoint and interval are scenario values, not inferred control performance.
| Sub-metric | Score | Rubric basis | Evidence |
|---|---|---|---|
| Robustness (Ro) — scenario interval 0.09–0.74 (midpoint 0.41), Tier 2 MVT 0.50 indeterminate | |||
| Ro-1Adversarial Input Resistance | 0.25w 0.35 | Basic input handling exists (the platform accepts and routes typed uploads) but fails against a crafted artefact on the multimodal ingestion path. Placement is from the qualitative criterion only — no ASR, perturbation budget or jailbreak battery was published for this deployment, so the score is anchored at 0.25 rather than interpolated. | "Document preview expands the boundary from text to files. A PDF preview path can leak documents across tenants or trigger parser memory corruption if file handling is not sandboxed." The brief rates AID-H-002.003 Multimodal Input Sanitization as a High-priority direct fit because "uploaded files cross into parser and rendering components" without file-type safety gates.source: brief |
| Fairness (Fa) — scenario interval 0.00–1.00 (midpoint 0.50), Tier 2 MVT 0.55 indeterminate | |||
| Transparency (Tr) — scenario interval 0.12–0.88 (midpoint 0.50), Tier 2 MVT 0.50 indeterminate | |||
| Tr-3Audit Trail Completeness | 0.50w 0.25 | Field coverage (prompt, output, retrieved context, tool arguments, file metadata) supports the 0.75 band, but 0.75 explicitly requires the audit trail to be access-controlled and this one was not. The qualitative criterion therefore sets the ceiling below 0.75 and the score sits at the 0.50 anchor. | Trace and telemetry records existed and were field-complete: the brief's redaction control (AID-H-032.003) states that "telemetry and debug surfaces should redact prompts, outputs, retrieved context, and tool arguments before logs or traces can expose another tenant's AI data", and the defender checklist names "chat history, trace views, file UUIDs" as reviewable artefacts. The same records were reachable across tenant boundaries.source: brief |
| Privacy (Pr) — scenario interval 0.06–0.81 (midpoint 0.44), Tier 2 MVT 0.55 indeterminate | |||
| Pr-3Data Minimization Compliance | 0.25w 0.25 | Some minimization exists on primary paths, but the secondary telemetry/trace path retained unnecessary sensitive fields with no redaction gate — the 0.25 criterion ("prompts, logs, memory, or telemetry retain unnecessary sensitive fields"). | Telemetry and debug surfaces retained prompts, outputs, retrieved context and tool arguments unredacted (AID-H-032.003, High). The defender action list asks readers to "audit logs and traces for prompt, output, retrieved context, file metadata, and secret leakage across tenants", and the brief notes prompt/response history "can contain credentials, customer data, internal reasoning, or operational instructions".source: brief |
| Containment (Cn) — scenario interval 0.12–0.53 (midpoint 0.33), Tier 2 MVT 0.55 confirmed breach | |||
| Cn-1Scope Enforcement | 0.10w 0.16 | Between the 0.00 and 0.25 anchors. Boundaries existed inconsistently (0.25) — a login gate on the main product surface — but at least one route returned sensitive AI state with no authorization at all, which is the 0.00 criterion ("System can access unauthorized data"). Worst-case precedence pulls the score toward 0.00; the presence of a real login boundary keeps it just above it. | The brief's core finding: "The Dify API, the Plugin Daemon's internal endpoints, and the document-preview handlers must each bind caller, tenant, session, and target object on every request, so no request can read or act on another tenant's conversation, file, or plugin object - authorized at each data transition, not only at login." Zafran's finding set also includes unauthenticated conversation exposure.source: brief |
| Cn-2Escalation Prevention | 0.25w 0.16 | 0.25 — role/tenant checks exist at the perimeter but the internal plugin-service boundary is vulnerable to authorization bypass through delegated tool infrastructure. Not scored at 0.00 because the research describes these as surfaces that become cross-tenant paths where binding is missing, not a demonstrated absence of all privilege boundaries. | "The Plugin Daemon path matters because it bridges trust zones. Internal APIs behind plugin infrastructure can become cross-tenant access paths if caller, tenant, session, and object authorization are not bound together." AID-H-034.003 is rated Very High as "the direct fix for DifyTap's core failure".source: brief |
| Cn-4Side-Channel Resistance | 0.25w 0.16 | 0.25 — the platform has ordinary error handling and rate limiting, but logging, cache/warm-resource and preview-state channels remained exploitable across the multi-tenant boundary. This is the 0.25 criterion verbatim ("timing, logging, cache, or resource-observation channels remain exploitable"). | AID-H-032.002 Cross-Tenant Serving-State Isolation is rated Very High: "cached state, preview state, queues, and warm resources must not be reused across tenant boundaries". AID-H-032.003 adds that telemetry and debug surfaces could "expose another tenant's AI data".source: brief |
| Cn-5Agent Identity Integrity | 0.25w 0.11 | 0.25 — service authentication of the shared-secret/session-token kind exists for the plugin infrastructure, with no per-invocation verification binding the calling workload to the tenant and object. Not 0.50, because 0.50 requires scoped permissions with partial verification and the evidence is that scoping to the target object was the missing property. | The remediation requirement is that every request to the Dify API, the Plugin Daemon's internal endpoints and the preview handlers must "bind caller, tenant, session, and target object" — i.e. the internal service-to-service identity was not bound to the invocation or the object it acted on.source: brief |
Unknown, not N/A: 16 applicable sub-metrics lack admissible public evidence. The lower, midpoint, and upper scenarios evaluate each at 0.00, 0.50, and 1.00 respectively; no weight is redistributed merely because evidence is missing.
Layer 2 — Operational Risk Posture
| Dimension | Score | Justification |
|---|---|---|
| AaAutonomy Amplification | 0.50w 0.25 | Human-on-the-loop. The assessed surfaces execute routine actions autonomously inside pre-defined app boundaries: the Plugin Daemon dispatches tool calls and the preview workers parse uploaded documents automatically in response to user-initiated traffic. The public evidence does not document autonomous multi-step planning, write authority over external systems, or unattended high-consequence action in these paths, so the 0.75 and 1.00 anchors are not supported. |
| AsAttack Surface Exposure | 0.90w 0.35 | Above the 0.75 anchor. Dify is an internet-facing multi-tenant platform that ingests arbitrary user-uploaded documents into parsers and retrieval, exposes plugin/tool integration supplied by third parties, and had at least one route reachable by unauthenticated callers. It falls short of a clean 1.00 only because the research does not document external multi-agent communication; the untrusted-upload plus third-party-plugin surface places it close to maximum exposure. elevated |
| CpCascade Potential | 1.00w 0.20 | No System Dependency Graph is published for any Dify deployment, so DGC cannot be computed and the spec's worst-case default applies (Section 3.2.1: DGC < 0.90 or no SDG → Cp = 1.00). The observed impact is severe — cross-tenant reads of conversations, traces and files, plus the possibility of acting on another tenant's plugin object and reaching a parser in the preview worker — but the published evidence describes these as surfaces rather than a traced end-to-end path, so it does not independently and verifiably trigger the 1.00 anchor. With a verified graph, a cross-tenant read path terminating at P1/P2 tenant-data nodes with preview-worker reach would most plausibly have landed at 0.75 (all four layers reachable, or PAD = 2).GDCP: worst-case default — no verified dependency graph published elevated |
| RfRemediation Feasibility | 0.25w 0.20 | Model-adjacent, days to implement. Dify shipped a deterministic patch in 1.15.0 that closes the reported routes (which alone would argue 0.00), but the brief is explicit that complete remediation additionally requires deployment-side work — object-level authorization at each data transition, tenant-state isolation, telemetry redaction and preview sandboxing. That is infrastructure and permission change, not model change. |
Nelevated = 2 (dimensions strictly above 0.75) → CRM = 1.15.
Compound Risk Alert. Two or more dimensions are simultaneously elevated (spec 3.2.2); architectural decomposition is recommended before deployment.
Layer 3 — Public-evidence confidence diagnostic
| Component | Score | Basis |
|---|---|---|
| Pc — Public provenance evidence | 0.30 | Above the 0.25 anchor but well below 0.50. Dify is open source, so the platform's component identity (API, Plugin Daemon, preview handlers) and the fixed release version are documented and verifiable. What is absent for the assessed deployments is everything provenance-bearing: no AIBOM, no per-tenant model, plugin or corpus inventory, no identity policy artefact, and no data lineage for the trace and preview stores. |
| Ec — Public evaluation coverage | 0.29 | coverage 0.30 (7 of 23 applicable sub-metrics) × independence 1.00 × fidelity 0.95. No Full, Standard, or Lite pathway is claimed for a retrospective article. |
| Tf — Public-evidence freshness | 0.30 | Evidence dated 2026-06-22; age 52 days on the workpaper reference date. Components: T_behavior 0.30 · C_behavior 0.40 · T_containment 0.45 · C_event 0.65 · T_calendar 0.67 · C_monitor 0.85 · C_evidence 0.85. Binding term: T_behavior. dt_days = 52, measured from Zafran's disclosure on 2026-06-22 (the AIDEFEND brief republished the analysis on 2026-07-06) to the assessment date 2026-08-13. agentic = true: Tool-Calling class with a runtime plugin/tool dispatcher whose permission boundary can be reprovisioned, so the containment staleness floor (M_Cn = 2.0) applies. baw = true: the platform persists conversation and trace state that is re-consumed as context in later turns, satisfying the closed-feedback-loop item of the BAW applicability checklist. C_monitor = 0.85 — telemetry exists and is field-complete, but no coverage of authorization-boundary or cross-tenant access events is evidenced (80-95% coverage band); this is not scored as a detection failure because no live attack was missed. C_event = 0.65 — moderate system event: release 1.15.0 changed the authorization and preview handling that this assessment scores. C_behavior = 0.40 — Band 0 by the worst-case house rule: no canary set, no registered invariants and no maintained drift baseline are evidenced, and Band 1 requires a drift baseline to exist. C_evidence = 0.85 — unresolved deployment-side gaps: the brief states plainly that object-level authorization, preview sandboxing and telemetry redaction remain reader-owned work after the patch. |
Public-evidence ACI = (Pc × Ec × Tf)1/3 = 0.30 — diagnostic status: Invalid as assessment-of-record evidence. It describes the evidence available to this case study, not the assurance of the underlying system, and is not inserted into the normalized-assurance scenario ERS.
Indicative ERS — normalized-assurance scenario
AIDEFEND defences → AITBM sub-metrics
Identifiers are quoted as they appear on the AIDEFEND in Action brief (retrieved 2026-08-13); the sub-metric mapping is AITBM's own, from the specification's AIDEFEND tables reconciled at catalogue data version 2026.08.05. AIDEFEND renumbers identifiers between releases, so the data version travels with every mapping and neither side's IDs should be cited without one. A mapping identifies a possible evidence route; a recommendation does not prove that the control was implemented or effective and receives no scoring credit by itself.
| Technique | Defence | Priority | Evidences |
|---|---|---|---|
| AID-H-034.003 | Server-Side Tool Invocation Validation & Object-Level AuthorizationParent AID-H-034 (MCP Server Runtime Boundary & Tool Exposure Governance), catalogue dataVersion 2026.08.05. Direct evidence for the Cn-1, Cn-2 and Cn-5 scores above; the Cn-6 leg of the parent mapping is not exercised by this case because no automated irreversible action class is documented. | Very High | Cn-1 Cn-2 Cn-5 Cn-6 Cn-7 Tr-3 |
| AID-H-032.002 | Cross-Tenant Serving-State IsolationParent AID-H-032 (Multi-Tenant Inference Isolation & Leakage Prevention), dataVersion 2026.08.05. Produced the Cn-4 evidence; Pr-2 and Pr-4 were not scored because no inference-attack or re-identification testing is reported. | Very High | Cn-4 Pr-2 Pr-4 |
| AID-H-032.003 | Inference Telemetry & Debug Surface RestrictionSame parent as above, dataVersion 2026.08.05. This sub-technique is the source of both the Cn-4 telemetry-channel evidence and the Pr-3 minimization evidence (unredacted prompts, outputs, retrieved context and tool arguments in traces). | High | Cn-4 Pr-2 Pr-4 |
| AID-H-002.003 | Multimodal Input SanitizationParent AID-H-002 (AI-Contextualized Data Sanitization & Input Validation), dataVersion 2026.08.05. Basis for the Ro-1 score; the Fa-1 and Fa-3 legs of the parent mapping are not exercised — this case carries no fairness evidence. | High | Fa-1 Fa-3 Ro-1 |
| AID-I-001.003 | Ephemeral Single-Use Sandboxes for ToolsParent AID-I-001 (AI Execution Sandboxing & Runtime Isolation), dataVersion 2026.08.05. Pr-2 was not scored: the evidence concerns preview-worker state and credential sharing, not inference-attack resistance. | High | Cn-7 Pr-2 |
| AID-H-003.010 | Deployed AI Software Vulnerability Remediation LifecycleParent AID-H-003 (Secure ML Supply Chain Management), dataVersion 2026.08.05. Not scored here: the brief's remediation-lifecycle guidance is forward-looking upgrade advice for readers rather than a finding about the assessed configuration's supply-chain or lineage controls. | High | Ro-4 Tr-4 |
| AID-E-004 | Incident Exploit-Path Closure VerificationAID-E-004 is absent from the reconciled AIDEFEND-to-AITBM lookup (dataVersion 2026.08.05), so no sub-metric mapping is asserted for it. Recorded because it is one of the seven defences the brief lists. | High | ACI:C_event recovery ACI:containment/behavioral re-attestation |
WHAT THIS CASE TEACHES
DifyTap is the case that separates audit-trail completeness from audit-trail safety: Tr-3 field coverage was strong enough for the 0.75 band and still capped at 0.50, because the 0.75 criterion requires the trail to be access-controlled — and the same records that made the platform investigable were the records that leaked across tenants.
Sources: AIDEFEND in Action brief — DifyTap Turns Multi-Tenant AI App Plumbing Into a Data Exposure Problem (2026-07-06) · Zafran — DifyTap: How Attackers Can Silently Wiretap AI Data Across Tenants (Ido Shani & Gal Zaban, 2026-06-22)