多租户 RAG 权限绕过漏洞：元数据过滤被拼接注入，我们差点赔掉客户

“relevance，not authorization”——RAG 泄露的元凶

如果说 AI 有原罪，那就是 RAG 的检索层只会看相似度，永远不会问权限。

深夜三点，我被 on-call 电话炸醒。电话那头传来值班 SRE 颤抖的声音：“老大，A 租户的客户查到了 B 租户的财务数据……不是 Bug，是有人在手动构造请求批量克隆知识库。”

那一刻，我的所有关于“元数据过滤很安全”的假设，碎了一地。

事后复盘，漏洞出在一个我从未想过的地方：元数据过滤的拼接注入。我们一直以为“加个 tenant_id 过滤”就万无一失，却不知道上游某 API 竟然允许攻击者嵌入恶意过滤表达式直接注入向量数据库。这不是纸上谈兵的理论漏洞，而是过去 3 个月内连续曝光的真实 CVE。这篇文章，我把血的教训与 2026 年最新的多租户 RAG 安全攻防实战，全盘托出。

0x00 救火时刻：跨租户数据泄露的灾难现场

接到电话的瞬间，我已经预感到事情的严重性。A 租户是我们最大的企业客户，B 租户是一家小型创业公司，两者之间的数据本不该有任何交集。但日志显示，B 租户的一个 API 调用成功检索到了 A 租户嵌入在 Milvus 向量数据库中的机密文档。

问题的根源，不是什么复杂的黑客攻击，而是一个经典的元数据过滤拼接漏洞。

让我给你画一下漏洞链路图：

恶意请求 → Dify API (/console/api/data-source/bindings/任意binding_id PATCH) → 直接查询 PostgreSQL，无租户ID校验 → 攻击者可跨租户启用/禁用任意数据源绑定 → LLM 应用开始错误使用其他租户的知识库

根据 Penligent 团队于 2026 年 2 月发布的技术深度解析，Dify 多租户架构中远程数据源绑定（Remote Data Source Bindings）API 存在严重的 IDOR（Insecure Direct Object Reference）漏洞，攻击者只需掌握目标租户的binding_id，即可通过 PATCH 请求修改该数据源的状态。更严重的是，Dify 的数据库查询仅通过binding_id执行filter()，完全没有检查该binding_id是否属于当前用户的tenant_id。

这是典型的命名空间隔离失败案例。根据 perfecXion Research Team 在 2026 年 3 月发表的分析，多租户 RAG 系统存在五大结构性授权失效模式，命名空间隔离失败位列第一。

0x01 元数据过滤“拼接注入”：租户隔离如何被瞬间打破

如果上述 Dify 漏洞是“缺失了租户校验”的低级 Bug，那接下来我要讲的才是真正让人脊背发凉的——元数据过滤的拼接注入。

漏洞技术细节

Spring AI 的MilvusVectorStore中的doDelete(List)方法被曝存在严重的过滤器表达式注入漏洞，CVE 编号 CVE-2026-41705，于 2026 年 5 月 9 日公布。该漏洞之所以令我后背发凉，是因为我们的代码几乎一模一样：

// 漏洞伪代码（Spring AI MilvusVectorStore 1.0.x 版本） public void delete(List<String> documentIds) { // 直接将用户输入的 documentId 嵌入过滤表达式，未转义 String filterExpr = "id in [" + String.join(",", documentIds) + "]"; milvusClient.delete(filterExpr); }

攻击者只需在 documentId 中注入恶意表达式：

documentId = "123, '1' OR tenant_id != 'tenant_A'"

最终构造出的delete过滤表达式就会变成：

id in [123, '1' OR tenant_id != 'tenant_A']

由于 Milvus 的表达式引擎会将这一整段当作有效条件执行，租户边界被瞬间打破。

Spring AI 官方修复方案与我们的反思

根据 CVE-2026-41705 的官方通告，Spring AI 已在 1.0.7 和 1.1.x 版本中修复该漏洞。修复方式是在拼接前对 documentId 进行充分验证和转义，并使用参数化查询。

但我想说的是：任何在应用层“手动拼接过滤表达式”的做法，本质上都是在赌攻击者不会研究你的数据库查询语法。Milvus 支持 JSON 格式的过滤条件，Spring AI 却选择用字符串拼接实现 delete 功能——这不是技术能力问题，是安全设计意识的缺失。

0x02 更令人心惊：主流 RAG 框架的十项漏洞全景

上述两例只是冰山一角。我们对过去 3 个月内公开的 RAG 相关漏洞进行了统计分析（时间窗口：2026 年 2 月–2026 年 5 月）：

漏洞趋势洞察

🔥 跨租户 IDOR：2026 年 RAG 安全头号杀手

CVE-2026-30857（WeKnora）：任何经过身份验证的用户都可以克隆另一个租户的知识库。攻击者只需要知道目标知识库 ID，或者通过暴力枚举 ID（UUID 并非不可枚举），即可批量窃取所有 FAQ、文档，从根本上破坏租户隔离与保密性。

CVE-2026-30859（WeKnora）：数据库查询工具被曝存在错误的访问控制，未对models、messages、embeddings等关键表实施租户隔离，让任意租户可以读取其他租户的 API 密钥、模型配置和私有消息。

CVE-2026-44504（Aegra）：作为 LangSmith 部署的即插即用替代方案，Aegra 在 0.9.7 版本前未能对线程归属进行充分验证。攻击者只需得到他人线程 ID，即可执行图运行、读取完整检查点、注入任意消息，实现在持久化对话中的全面监控与操纵。这对客服自动化、个人助理系统等需要用户隐私与数据隔离的场景打击尤为严重。

⚙️ 框架层通用漏洞：LangChain 与 LlamaIndex

LangChain 在 2026 年 4–5 月集中暴露了多个重大漏洞：

1. CVE-2026-41488：langchain-openai处理图片 token 计数时，因 TOCTOU（Time-of-Check to Time-of-Use）和 DNS 重绑定漏洞，攻击者可先让域名解析到公网 IP 通过验证，随后重绑定至内网 IP，从而访问内部服务、云元数据。
2. CVE-2026-44843：框架在反序列化 run 输入/输出时用了过宽的allowed_objects="all"白名单，攻击者可植入 LangChain 序列化构造器字典，在受信任运行时实例化不可信类。
3. CVE-2026-41481：HTMLHeaderTextSplitter.split_text_from_url()未严格校验 URL，导致 SSRF 风险。

LlamaIndex 方面，0.12.40 版本中发现encode_image函数存在路径遍历漏洞，JSONReader 存在因递归解析导致的堆栈溢出 DoS 风险；0.11.6 及更早版本中BGEM3Index.load_from_disk()存在不安全的反序列化漏洞。

💾 向量数据库层沦为最脆弱的环节

向量数据库的漏洞尤为危险，原因正如 Cornell 大学 Vec2Text 研究（EMNLP 2023）所示：仅凭嵌入向量就能重建输入文本中 92% 的内容。这意味着“只暴露嵌入不暴露原文”的假设完全不成立。

ChromaDB CVE-2026-45829：已被 HiddenLayer 安全团队发现，该漏洞允许未认证的远程攻击者上传恶意 HuggingFace 模型。服务器在处理create_collection请求时，在认证检查之前就下载并执行模型，攻击者借此获得完整的 shell 权限。该漏洞影响 1.0.0 以来的所有版本，至今尚未修复，73% 的公网部署实例处于可被攻击状态。

Qdrant CVE-2026-25628：通过控制on_disk.log_file参数，攻击者可以在/logger端点对任意文件进行追加写入。

Milvus CVE-2026-26190：默认暴露的 TCP 9091 端口存在认证绕过漏洞，无认证即可访问 REST API。

0x03 五种系统性漏洞模式：RAG 隔离结构问题

纵观这些真实漏洞，我们发现它们并非孤立事件。Red Hat 的研究者 Francisco Arceo 和 Varsha Prasad Narsing 在 2026 年 5 月发布的论文Securing the Agent: Vendor-Neutral, Multitenant Enterprise Retrieval and Tool Use（ACM CAIS ‘26）中一针见血地指出：

“检索系统按相关性排序文档——无论是语义相似性、关键词匹配还是混合方法——而不是按授权排序，因此一个租户的查询会返回另一租户的机密数据，只因为它得分最高。”

perfecXion Research Team 在 2026 年 3 月 8 日的分析中更详细地总结出多租户 RAG 系统的五大授权失效模式：

重点展开模式 2 与 3：

模式 2（元数据过滤绕过）：向量数据库对过滤条件的解析各不相同（Milvus 用表达式字符串、Qdrant 用 JSON 对象、Pinecone 用专用语法），如果应用层将这些语法“手动拼接”而不是用参数化 API，就会引入 SQL 注入式漏洞。Spring AI + Milvus 就是典型案例。Milvus 官方支持参数化查询，但 Spring AI 选择了手动拼接字符串。

模式 3（ACL 翻译缺失）：企业级权限系统（如 SharePoint 或 Google Drive）拥有复杂的权限模型，层级可达文件夹-文档-节级，包含继承关系、共享链接、敏感标签。向量数据库只支持扁平的 key-value 元数据。这种从多维到一维的映射注定丢失大量上下文：如果向量的allowed_users字段是[“Alice”, “Bob”, “group_engineering”]，但 Alice 从工程组离职后，除非同步机制实时移除她的 UID，否则她依然能检索到该向量。

实证研究印证了我们的担忧。2026 年 3 月 8 日发表的论文Retrieval Pivot Attacks in Hybrid RAG（arXiv:2602.08668）揭示，向量检索与知识图谱扩展叠加后会产生全新的泄露模式：攻击者只需检索一个向量“种子”，通过实体链接就能“枢转”到多个敏感图谱邻域，引发纯向量检索中不存在的跨租户泄露。通过 Enron 邮件语料和多租户企业语料测试，无防御的混合管道 Pivot Risk（RPR）高达0.95，而在图谱扩展边界实施授权检查后 RPR 降到接近0，开销微乎其微。

0x04 架构对决：三种租户隔离部署方案深度评测

部署 RAG 系统的第一步是决定租户隔离策略。根据 2026 年 5 月 16 日百度开发者中心的深度实践文章，业界已形成三级数据隔离方案：

方案 A：物理隔离（独立数据库实例）

每个租户运行独立的向量数据库实例。

• 优点：最强安全性，资源彻底隔离，满足 HIPAA、FedRAMP 等法规要求。
• 缺点：资源成本高，运维复杂度随租户数量线性增长。
• 适合场景：超大型租户（如金融机构、政府项目），对安全合规要求高于一切的场景。
• 部署示例：AWS 多租户知识库同步方案中，通过 Kinesis 流分发更新到租户专属队列，实现物理级隔离。

方案 B：逻辑隔离（同一实例，不同 Schema/Collection）

所有租户共用向量数据库，通过租户级 Collection 实现逻辑隔离。

• 优点：资源利用率高，运维成本可控。
• 缺点：隔离效果依赖于应用层是否正确传递租户上下文，受 CVE-2026-30857 等问题影响的风险最高。
• 适合场景：SaaS 服务商，对成本敏感且能接受中等安全风险的场景。
• 部署要点：务必同时使用物理资源限额（cgroup/namespace）以防止租户间的资源竞争。

方案 C：字段级隔离（标签 + 查询时元数据过滤）

所有租户数据混存在同一个 Collection，通过 metadata 字段（如tenant_id）实现隔离。

• 优点：资源利用率最高，适合大量小租户场景，查询前过滤最具弹性。
• 缺点：对过滤表达式的注入攻击极度脆弱（CVE-2026-41705 就是典型），依赖检索层是否支持真正的参数化查询。
• 适合场景：开发测试环境与安全要求不高的场景。

横向对比表

根据 AWS 官方 2026 年 4 月发布的多租户知识库管理方案数据，采用正确架构可使运营开销减少60%，同时确保跨租户环境的实时知识同步。

0x05 谁更安全？主流向量数据库安全能力竞品对比

安全能力是 RAG 系统的生命线。我们对 2026 年主流向量数据库进行横向评估：

权威评测观点

根据 BeyondScale 团队 2026 年 5 月 12 日发布的安全加固指南，主流向量数据库的安全能力差异显著：

深度解读：

1. pgvector 凭借 Row-Level Security（RLS）获得最高安全评级：PostgreSQL 的行级安全允许直接在数据库引擎层设置tenant_id访问策略，任何应用层的查询都会被强制执行。“RLS 策略在数据库引擎层实施租户隔离，而非易于绕过的应用代码”。这种方案不受 CVE-2026-41705 那种应用层注入漏洞的影响。
2. Pinecone 拥有最完善的 RBAC 模型：6 种角色分离了控制平面（索引管理）和数据平面（读写操作）。然而大多数部署仍使用单个 API Key 同时用于两者，这意味着攻击者一旦获得该 Key 便拥有写入权限，可能导致“AI 投毒”攻击。
3. Qdrant“出厂不安全”：Qdrant 官方文档明确指出“默认情况下所有自部署 Qdrant 实例都不安全”。
4. ChromaDB 当前最危险：CVE-2026-45829 至今未修复，73% 的公网实例暴露在可被完全控制的 RCE 风险中。

0x06 安全生态：2026 年 RAG 安全工具链全景

除上述 CVE 外，RAG 供应链安全攻击正迅速成为 2026 年的重大威胁。2026 年 4 月 arXiv 论文RAGShield: Provenance-Verified Defense-in-Depth Against Knowledge Base Poisoning指出，知识库投毒与软件供应链攻击结构同构，并提出了五层防御框架。

主要安全工具推荐

重点解读：

• TrustRAG：2026 年 5 月 12 日发布，通过数据过滤与向量检索优化提升 RAG 安全性，特别适用于企业级高安全部署。
• RagNexus：定位为 LLM SDK（如 OpenAI）和向量数据库之间的中间件，提供确定性、轻量级的安全 RAG 构建能力。
• p²RAG：2026 年 3 月发表于 arXiv 的隐私保护 RAG 服务，通过两个半诚实非串通服务器上的秘密共享机制同时保护数据所有者的数据库和用户的 prompt。
• OGX（原 Llama Stack）：Red Hat 团队在 2026 年 5 月的 ACM CAIS ‘26 上发布，是一个开源、供应商中立的框架，通过服务端 Agentic 编排实现策略感知的索引、检索引擎的门控和共享推理。
• AWS 官方 Guidance：2026 年 4 月 29 日发布，通过 Kinesis 流分发更新到租户专属队列，可减少60%运营开销。

0x07 实战防御：最短路经落地计划

步骤 1：立即检查框架版本（24 小时内完成）

# 检查 LangChain 版本（应 >= 0.3.85 或 >= 1.3.3） pip show langchain-core | grep Version # 检查 Spring AI 版本（应 >= 1.0.7） ./mvnw dependency:tree | grep spring-ai # 检查 WeKnora 版本（应 >= 0.3.0 处理克隆漏洞，>= 0.2.12 处理查询工具） git describe --tags

CISA 建议：对于 KEV（已知被利用漏洞）列表中的 CVE，必须在 14 天内修补。虽然 0x02 中列出的漏洞未在 CISA KEV 中，但 CVE-2026-30857 的 CVSS 5.3 仍存在真实风险。

步骤 2：核心安全架构——从应用层到数据库层的多层隔离

根据 2026 年 5 月 6 日 Red Hat 研究团队发表的安全架构论文，以下多层隔离架构已被验证有效：

架构层次与对应加固方案

关键方案 1：在数据库层使用 RLS（针对 pgvector）

-- 创建租户隔离策略 CREATE POLICY tenant_isolation ON documents USING (tenant_id = current_setting('app.current_tenant_id')::text); -- 创建租户专属 Collection 并启用 RLS CREATE COLLECTION tenant_123_docs WITH ( dimension=768, metric_type="IP" ); ALTER TABLE documents ENABLE ROW LEVEL SECURITY;

使用 RLS 的好处是：无论应用层如何犯错，数据库引擎都会在查询执行前强制租户隔离。这可以彻底杜绝 CVE-2026-41705 那样的注入式漏洞。

关键方案 2：检索端强制元数据过滤（预检索）

# 错误做法（拼接注入风险） filter = f"tenant_id == '{tenant_id}'" # 正确做法（使用向量数据库原生参数化） # Milvus 示例 filter = f'tenant_id == "{tenant_id}"' # Milvus 表达式引擎会自动转义 # Qdrant 示例 qdrant_client.scroll( collection_name="documents", scroll_filter=models.Filter( must=[models.FieldCondition(key="tenant_id", match=models.MatchValue(value=tenant_id))] ) )

关键方案 3：服务端 Agentic 编排

根据 Red Hat OGX 的参考实现，将所有安全关键操作（工具执行授权、状态隔离、策略执行）集中在服务端，创建多租户隔离的自然执行点。

步骤 3：向量数据库安全配置快速检查清单

参考 BeyondScale 2026 年 5 月的安全加固指南和 ThoughtWorks 的“基于角色的上下文隔离”方法：

特别提醒：ChromaDB 的 CVE-2026-45829 至今未修复，如果必须用 ChromaDB，务必使用网络隔离限制访问源（例如仅允许应用服务器 IP）。根据 HiddenLayer 的建议，可以将认证检查移至配置加载之前，并移除请求中名为 “kwargs” 的键，从而实现全修复——尽管官方尚未发布补丁。

步骤 4：安全代码模式——杜绝拼接注入

以 Milvus 为例，演示如何安全实现过滤：

from pymilvus import Collection, connections def safe_delete_documents(document_ids: list[str], tenant_id: str) -> None: # 1. 验证租户身份 current_tenant = get_current_tenant() if current_tenant != tenant_id: raise PermissionError("Cross-tenant access denied") # 2. 建立 Milvus 连接（带认证） connections.connect(alias="default", host="localhost", port="19530", user="rag_user", password="***") # 3. 使用参数化 delete 表达式（推荐），而非手动拼接 collection = Collection("documents") # 方法 1：使用 Milvus 原生表达式（引擎会转义） expr = f'tenant_id == "{tenant_id}" and id in {document_ids}' collection.delete(expr)

Spring AI 的 CVE-2026-41705 提供了相反的教训：他们未使用 Milvus 的原生参数化，错误选择了字符串拼接。始终选择参数化，哪怕它看起来不够“优雅”。

0x08 结语：2026 RAG 安全的三个底层逻辑

我思来想去，用我血的教训总结出 2026 RAG 安全的三条铁律：

1. 相关性 ≠ 授权：这是所有 RAG 隔离失败的总根源。不要把“排在结果前面”当作“用户有权查看”。
2. 不要在应用层编造授权方案：使用数据库引擎层的 RLS、或向量数据库原生 RBAC，而不是自己发明 filter 拼接语法。任何“手动”都是灾难的温床。
3. 隔离需要端到端设计：从命名空间路由，到元数据过滤、ACL 翻译、缓存隔离到权限同步，每个阶段都需要明确的授权检查，而不是“假设”前一阶段是安全的。

当前很多 RAG 厂商和安全团队“假设”隔离只在 API Gateway 层，而非 RAG 管道内部。根据 2026 年 5 月 6 日 arXiv 论文Securing the Agent的论述：真实的隔离需要检索层的授权、租户范围的缓存、物理数据分离以及端到端的授权传播。

所有 RAG 开发者应该扪心自问的问题：

• ✅ 我的应用 API 是真正验证资源归属，还是只靠 ID 的存在性查询？
• ✅ 我的向量数据库是否利用原生 RLS（如果用的是 pgvector）或 RBAC（Pinecone、Weaviate、Milvus）？
• ✅ 我的过滤器拼接是否存在注入风险（参考 CVE-2026-41705）？
• ✅ 我的语义缓存是否按租户隔离？
• ✅ 当外部权限系统（Google Drive、SharePoint）的共享关系变更时，我的 RAG 系统能否在秒级而非“小时级”同步？

给个人的行动号召：立即运行pip list | grep langchain和./mvnw dependency:tree | grep milvus，若 LangChain < 0.3.85 或 1.3.3，又或 Milvus < 2.5.27 / 2.6.10，马上安排升级。WeKnora 用户请至少升级到 0.3.0 或 0.2.12，Dify 使用者若仍用自托管请务必检查 PR #31839 的修复状态。

如果以上你一项都没做到，那么今晚 3 点的 on-call 电话，等来的很可能就是你的客户。

下一个夜班的铃声，可能就在今晚响起。