TrendAI™ Research 如何協助解決 Dify 登入後流程中的開放式重導漏洞

摘要

TrendAI™ Research 在 Dify 的登入後認證流程發現了一個開放式重導 (open direct) 漏洞 (ZDI-26 -452 / CVE-2026-18266，CVSS 5.4)。該漏洞可讓駭客使用一個未被濾的網址參數，將通過認證的使用者在登入後立即重導至駭客掌控的目的地。接著，駭客會取得一個認證權杖來讓自己以使用者的身分採取行動。Dify 在 7 月 13 日發布了更新來修正此問題。

Dify 是什麼？為何這問題很重要？

在了解漏洞本身之前，我們先來了解什麼是 Dify，以及這個漏洞為何嚴重。目前 Dify 已悄悄成為打造 AI 應用程式的首選平台之一，所以像登入這麼稀鬆平常的流程萬一出現漏洞，影響的使用者數量可能相當驚人。

Dify 是一套開放原始碼 LLMOps 平台，用來打造 AI 工作流程、聊天機器人及 AI 代理，它提供了視覺化開發工具、RAG 流程、模型管理，以及可觀察性。目前，Dify 已成為部署最廣泛的 AI 應用程式平台之一，擁有超過 14 萬顆 GitHub 星星，其 API Docker 映像已累積了 1,000 多萬次拉取 (pull)，並且被部署在數十種產業當中。它提供了兩種部署模式：自行代管以及分租共用雲端服務 (cloud.dify.ai)，這意味著此漏洞有可能對其他租戶造成風險。

Dify 的熱潮主要集中在亞太地區，但也逐漸受到西方企業青睞，用於開發面向客戶的 AI 聊天小工具，本漏洞就是出現在經由這個小工具登入的途徑 (Dify 的可內嵌網站應用程式登入流程)。此外，本漏洞也完全對應到 TrendAI™ Research 所稱的「LLM 工具和應用程式」類別，也就是 AI 相關 CVE 漏洞成長最快速的來源，包括：程式碼注入、伺服器請求偽造 (SSRF)、路徑瀏覽，以及一些重新出現在新式 AI 工具中的經典網站驗證漏洞 (例如本案)。

漏洞：未經檢驗的登入後重新導向

本案的問題是，登入後流程在未先執行徹底檢驗的情況下便直接信任重導目的地，而且由於該目的地是來自一個網址參數，因此只需一個精心特製的網址，便能將它帶到不該去的地方。實際上，這意味著一個剛完成認證的連線階段、權杖等等，都可能被帶到駭客所掌控的網站。

位置： Dify 的登入後重新導向處理機制，包括各種認證途徑：標準的登入表單、單一簽入 (SSO) 認證、郵件+認證碼，以及可內嵌網站應用程式登入流程 (當它的聊天小工具架設在第三方網站時)。
問題：登入後的重導目標未經過充分檢驗，使得剛完成認證的連線階段可被轉移至駭客掌控的外部網址。
影響：連線階段和權杖被駭客掌控，使得剛通過認證的使用者連線階段遭到挾持 (CVSS 5.4)。
揭露管道： TrendAI™ Zero Day Initiative™ (ZDI)，由 ZDI 經由其標準的負責任揭露流程與 Dify 聯合通報。這項發現目前已指派編號來加以追蹤：ZDI-26-452 (CVE-2026-18266)。

解決之道：重新改寫了一套集中式重新導向檢驗機制

Dify 捨棄了局部性修補，推出一套重新大幅改寫的機制，變更了 36 個檔案以及大約 1,850 行程式碼 (PR #38864，feat/login-redirect-security)，包括：

設計一套全新的集中式重新導向檢驗工具 (login-redirect.ts) 並用於每一種認證途徑 (標準登入、SSO、郵件+認證碼、內嵌式網站應用程式登入、邀請流程、權杖更新)。
明確拒絕使用通訊協定相對路徑 (//) 及反斜線 (/\) 路徑的重新導向目標，也就是開放式重導最常見的兩種迴避技巧。
使用遞迴解碼處理來揪出雙重/三重 URL 編碼的惡意網址。
拒絕內嵌登入憑證的主機 (user@evil.com 技巧)。
一套針對絕對重導目標的允許清單模型：僅允許 dify.ai 和 *.dify.ai 的網址，並透過 HTTPS 以及預設連接埠，除此之外，其他全部回復到安全的預設方式。
一套新的端對端測試套件 (e2e/features/auth/redirect-security.feature)，專門用於往後的重新導向資安回歸測試。

揭露時間表：從通報到公開修正

此漏洞的整個通報過程 (從私下揭露到公開修正) 大約花了四個月的時間，以下列出幾個重要日期：

2026-03-25 — TrendAI™ Research 將這個開放式重導漏洞通報給 TrendAI™ ZDI，ZDI 為該漏洞指定了一個追蹤編號：ZDI-CAN-29196。
2026-03-25 — ZDI 在同一天通知了 Dify，其標準的負責任揭露保密期限開始起算。
2026-07-13 — Dify 將所有修正合併成 PR #38864，並公開在 GitHub 上，此時尚未無 CVE、GHSA 公告或致謝資訊。
2026-07-23 — ZDI 的 120 天揭露保密期限屆滿，此時 ZDI 已經可以對外發布漏洞公告，不論廠商有沒有動作。
2026-07-29 — ZDI 針對該漏洞發布公告 (ZDI-26-452)，CVE 也指派了漏洞編號 CVE-2026-18266 (CVSS 5.4，CWE-601 開放式重導)。

為何這問題不只關乎 Dify

本案發現的漏洞符合了 TrendAI™ Research 在我們的 2026 年 AI 資安現況報告「AI 生態系中的隱藏斷層」(Fault Lines in the AI Ecosystem) 當中所記載的一種更廣泛的模式。該報告分析了 330,239 個 CVE 漏洞，並發現了 6,086 個影響 AI 系統的非重複漏洞，揭露期間從 2018 至 2025 年。在這些漏洞當中，光 2025 年就有 2,130 個，較前一年同期成長 34.6%，這數字幾乎是 CVE 揭露整體成長率 (17.9%) 的兩倍。我們預測 2026 年將再增加 2,800 至 3,600 個 AI 相關的 CVE 漏洞。

這份資料集當中有一個類別與本案直接相關：「LLM 工具和應用程式」，這是我們對 ChatGPT 出現後爆發的這波 RAG/AI 代理/聊天機器人建構平台 (Dify、Langflow、vLLM 和 AnythingLLM 等等) 的統稱。此類別囊括了 1,243 個 CVE 漏洞，占我們追蹤的所有漏洞中的 20.4%，其中最普遍的漏洞正是我們在主流網站應用程式中經常看到的：程式碼注入、SSRF 及路徑瀏覽。本案發現的 Dify 漏洞又在這份清單中增加了第四種漏洞：開放式重導與登入後流程，並印證了該報告的核心論點：這些平台正在重新發掘 (及重新修正) 一些成熟框架十年前就已解決的網站安全基本問題，因為該領域的功能開發速度已超越了資安審查的腳步。

不僅如此，這也不是 Dify 今年第一次浮上檯面。今年 2 月，有另外一名研究人員揭露了 Dify 登入端點 (GHSA-9qpf-wcv3-w3qx) 當中的一個使用者列舉漏洞。6 月份，Zafran Security 一個名為「DifyTap」的研究揭露了 Dify 的追蹤、擴充功能背景程式 (Plugin-daemon) 及檔案存取子系統中的四個漏洞 (兩個是重大漏洞)，使得 Dify 的分租共用雲端可能發生跨租戶資料外洩 (CVE-2026-41947 至 CVE-2026-41950)。我們的研究是 2026 年揭露的第三輪有關 Dify 的資安研究，與 DifyTap 形成了有用的對比：Zafran 的研究發現是架構層級的租戶隔離功能失效，這與 Dify 的分租共用 SaaS 打造的方式有關；而我們的發現則是一個經典的認證相關漏洞，就算在完全自行代管的單一租戶部署環境也會發生。如果兩者合起來，就算是當完整地描繪了一個平台的攻擊面，從基礎架構層級的隔離機制缺失，一路涵蓋至應用程式層級的認證錯誤，而這兩者都在六個月期間內被發現。

此外，本案發現的 Dify 漏洞也屬於我們團隊更廣泛追蹤的 AI 工具堆疊失敗情況之一。儘管我們針對 MCP 伺服器的研究顯示，目前正逐漸興起一股朝未認證曝險的趨勢，完全不涉及用戶端認證或流量加密。然而，光今年 ZDI 聯合揭露的漏洞就包括了 LiteLLM (包括一個 6 月份通報的 CVSS 8.8 漏洞) 和 mcp-kubernetes-server (CVSS 9.8)，以及本案的 Dify。儘管案例不同，但背後的故事都一樣，那就是：發展迅速且廣獲採用的 AI 基礎架構在底層框架經過嚴格資安審查之前便搶先推出。

給 Dify 使用者的建議

對正在使用 Dify 的企業來說，有幾個步驟可以防堵此漏洞，並確認它在被修補之前不會遭到攻擊。

企業應升級到 Dify v1.16.0 或更新版本，這些版本包含了 PR #38864 重新改寫的重新導向檢驗機制。這是最有效的單一步驟，因為它從源頭解決了問題，保護了每一個受影響的認證途徑。
那些在客製化反向代理器 (reverse proxy) 後方自行代管該平台的企業，應檢查代理器的組態設定，確認它不會將未經檢驗的重新導向參數傳送至外部目的地。因為如果代理器將這些參數外傳，同樣的開放式重導行為就會重演，即使應用程式已經修補完成。
此外，企業也應查看身分認證及重新導向記錄檔中是否有遭到漏洞攻擊的跡象，例如登入後重導至不熟悉的外部網域，或是非預期的 oauth_redirect_url 數值指向外部網站。