审计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。