部落格 發布於 AIA: 2026年7月6日

DifyTap：多租戶 AI 平台不能只靠登入來守住資料邊界

Zafran 的 DifyTap 研究串起 Dify（讓多個組織或團隊共用同一套服務的 AI 應用平台）中多條資料外洩路徑，包括未經授權的對話存取、Plugin Daemon（Dify 的外掛服務）的內部 API、跨租戶文件預覽，以及 PDF 預覽解析器中的安全漏洞。這不是修補單一漏洞就能解決的問題：多租戶 AI 平台必須在每個資料處理環節重新驗證物件層級的權限，隔離不同租戶的執行狀態，對遙測資料中的機敏資訊做適當遮罩（masking，移除或替換記錄中的機敏內容），並把文件解析工作放進隔離的沙箱環境。

Credential ExposurePrivacy LeakageData GovernanceSession IsolationMulti-Tenant AI
7 項對應的 AIDEFEND 防禦手法
來源: DifyTap: Zafran Discovers How Attackers Can Silently Wiretap AI Data Across Tenants on a Platform Powering 1M+ Apps 
作者: Ido Shani & Gal Zaban
原文發布: 2026年6月22日

威脅分析

  • 這個研究描述了多條可能讀取或外洩資料的路徑，不只是利用單一漏洞的攻擊路徑。 Zafran 描述 Dify 的多個功能介面，可能外洩私人 AI 對話、檔案、租戶識別資訊，或形成惡意文件攻擊解析器的路徑。
  • 對話與追蹤資料本身就是機敏的 AI 運作資料。 提示詞（prompt）、回覆、操作脈絡與追蹤資料可能含有憑證、客戶資料、內部推理或營運指令；如果未經身分驗證的使用者，或某個租戶的使用者能讀取另一個租戶的資料，就表示資料治理沒有做好。
  • Plugin Daemon 會跨越租戶信任邊界。 外掛基礎設施背後的內部 API 如果沒有同時綁定呼叫者、租戶、工作階段與後端物件權限，就會成為未經授權的跨租戶資料存取路徑。
  • 文件預覽把攻擊面從文字擴大到檔案。 PDF 預覽功能可能跨租戶洩漏文件，也可能讓惡意檔案在沒有沙箱保護的解析器中觸發記憶體破壞漏洞。
  • 部署方能做的不只是升級。 除了升級到 Dify 1.15.0 以上，也要在自己的部署環境驗證租戶隔離、記錄遮蔽、文件預覽是否在隔離環境執行，以及每次資料請求是否都有正確的授權判斷。

適用的 7 項 AIDEFEND 防禦手法

AID-H-034.003
Server-Side Tool Invocation Validation & Object-Level Authorization
極高
要修好 DifyTap 的核心問題，最直接的做法是把授權放到伺服器端，而且要檢查到「這個人到底有沒有權限碰這一筆物件」的層級。Dify API、Plugin Daemon 的內部端點、還有文件預覽的處理程式，每一個請求進來都要確認呼叫者是誰、屬於哪個租戶、哪個工作階段、要碰的是哪一筆物件；只要對不上，就不准讀到或改到別的租戶的對話、檔案或外掛。這個檢查要發生在每一次拿資料的當下，不能只在一開始登入時做一次。
AID-H-032.002
Cross-Tenant Serving-State Isolation
極高
跨租戶的服務狀態隔離直接對應核心風險：快取、預覽狀態、佇列與預先載入的資源，都不能跨租戶重複使用。
AID-H-032.003
Inference Telemetry & Debug Surface Restriction
高
遙測與除錯介面要先遮蔽提示詞、模型輸出、擷取內容和工具參數，避免記錄或追蹤資料成為另一條跨租戶外洩路徑。
AID-H-002.003
Multimodal Input Sanitization
高
多模態輸入清理和檔案安全檢查直接對應 PDF 預覽風險，因為上傳的檔案會進入解析器與畫面產生元件。
AID-I-001.003
Ephemeral Single-Use Sandboxes for Tools
高
把預覽解析器和外掛工具放進一次性沙箱，讓它們不保留長期狀態，也拿不到正式環境憑證；即使惡意文件攻破解析器，影響也會被限制在單次工作環境內。
AID-H-003.010
Deployed AI Software Vulnerability Remediation Lifecycle
高
追蹤 DifyTap 各條路徑實際影響的 Dify 與 Plugin Daemon 部署版本，重建並分階段 rollout 修正版，再以 fleet readback 證明沒有脆弱的應用程式或 plugin service 執行個體遺留。這項控制負責交付修補與完成驗證；AID-E-004 另行證明攻擊路徑已關閉。
AID-E-004
Incident Exploit-Path Closure Verification
高
Dify 與 Plugin Daemon 修正版部署完成後，應由獨立驗證方逐條重播事件定義的 DifyTap 路徑，確認 tenant/object authorization 與 parser 邊界已在受影響部署上拒絕原始請求。這是 closure verification，不負責 patch rollout 或 WAF 部署。

身為資安防禦者，我們應該這麼做

  • 升級至 Dify 1.15.0 或更新的版本，並確認實際部署的 Plugin Daemon、API 與文件預覽元件都已同步更新。
  • 針對對話歷史、AI 工作流程執行記錄、檔案識別碼、文件預覽端點和外掛內部 API，逐項測試是否會跨租戶讀到別人的資料。
  • 提示詞、回覆、追蹤資料和文件預覽，都要經過物件層授權；授權判斷必須同時綁定呼叫者、租戶、工作階段和後端物件。
  • 把 PDF 與其他文件預覽工作放進沒有長期租戶狀態、也沒有正式憑證的隔離環境。
  • 稽核記錄與追蹤資料，確認裡面沒有提示詞、模型輸出、擷取內容、檔案中繼資料或跨租戶祕密。

結論

DifyTap 提醒我們，多租戶 AI 平台處理的機敏資料，通常比一般 SaaS 操作介面更多。提示詞、AI 工作流程執行記錄、檔案、外掛呼叫資料和文件預覽結果，都必須在正確租戶的授權範圍內處理；不同租戶的工作階段和文件預覽工作也要彼此隔離。修補可以關閉已知漏洞；長期架構則要避免下一個功能或 API 再次形成相同的跨租戶資料外洩路徑。