審計200多款自託管AI工具的多租戶隔離性，發現78個存在資料洩露

一項針對多租戶AI和SaaS產品的安全研究揭示了一個普遍存在的漏洞模式。研究者對200多款自託管產品進行了原始碼審計，發現其中78款存在跨租戶資料洩露風險。漏洞的核心在於，寫入端點實施了許可權檢查，但相鄰的讀取端點（如列表、獲取、搜尋）卻缺乏同樣的保護。這種被稱為“未改造的讀取兄弟”的漏洞使得一個租戶能夠讀取、修改甚至刪除其他租戶的資料。

研究方法分為兩個階段：首先，透過原始碼掃描識別那些寫入有許可權檢查而讀取沒有的產品；然後，對疑似存在漏洞的產品進行實際驗證。研究者搭建了自託管Docker例項，建立了兩個租戶，並使用開源工具Sectum AI模擬跨租戶操作。每次成功利用都會生成一份帶有RFC-3161時間戳的證據包，並透過協調披露流程（90天保密期）報告給維護者。

在發現的84個具體漏洞中，有31個已作為GitHub安全公告提交。已修復並公開的產品包括：SurfSense（利用儲存的OAuth令牌重新索引聯結器以竊取其他租戶的GitHub/Notion內容）、AnythingLLM（嵌入小部件預設對匿名來源暴露）、Baserow（透過序列ID跨工作空間洩露欄位值）、aideepin（跨使用者讀取RAG塊文本、嵌入向量和文件文本）和Flagsmith（跨專案讀取多變數標誌值）。另外79個漏洞仍在協調披露中，詳細列表可在sectum.ai/research上檢視。

更隱蔽的是第二種變體：許可權檢查雖然執行，但驗證的是路徑而非實際物件。攻擊者可以提交自己工作區的ID（允許訪問）和受害者的物件ID，檢查透過卻訪問了其他租戶的資料。這種錯誤尤其危險，例如讀取嵌入向量可部分重建源文件，或利用受害者的OAuth令牌重新索引聯結器以提取資料。

在測試中，Open WebUI、Langfuse、LibreChat、Outline、PraisonAI、Onyx、LangWatch和Khoj等產品透過了隔離性驗證。而Flowise、Mem0、MaxKB和vLLM的開源版本並非多租戶架構，因此不存在跨租戶洩露面，但自託管時需注意隔離假設是否成立。

研究者給AI開發者提出了三點建議：第一，對讀取操作必須像對寫入操作一樣進行嚴格的許可權檢查，最好在查詢層、行級策略或中介軟體層面強制租戶隔離，而不是依賴每個端點自主選擇。第二，嵌入向量和快取鍵也應視為租戶資料，因為許多洩露並非文件本身，而是RAG向量或響應快取，其鍵缺少租戶標識。第三，自託管時務必驗證所假設的隔離性確實存在，不要輕信預設配置。

所有測試均在隔離的自託管例項上使用合成資料進行，未涉及生產系統。研究使用的開源工具Sectum AI可用於自動驗證多租戶隔離性，生成可審計的證據包。詳細披露列表將持續更新於sectum.ai/research。