RAG 把 LLM 输出 grounding 在外部知识库后,corpus 本身就成为攻击面。前五篇 LLM 安全纵深攻了输入(8 种注入)、调用(8 种越权)、工具表面(8 种投毒)、输出(8 种泄露)、memory 持久化(8 种投毒)。本文是第六维度 — corpus / knowledge base 持久化层 — 纵深专篇,把”corpus poisoning”从论文术语变成生产可落地的攻防手册。

corpus 攻击跟 memory 攻击的相似 + 区别:都是”持久化”,但 corpus 是企业级共享事实源(RAG 检索命中影响所有 user、所有 query);memory 是 agent 自学习本地状态(只影响单个 agent 实例)。RAGShield 论文披露的关键数据:10 个恶意 passage (0.04% corpus) 就能 98.2% retrieval success rate — 一次 corpus 注入,可以永久影响所有未来 query 的输出。

30 秒总览

  • RAG corpus 是 LLM 时代的第六维持久化攻击面 — OWASP LLM Top 10 2026 (9-1 发布) 把 corpus poisoning 列入主类目;Agentic Top 10 2026 ASI04 Agentic Supply Chain 是直接对位
  • 8 种 corpus 投毒(按 corpus lifecycle:数据来源 → ingestion → 存储 → retrieval → 影响输出):直接注入恶意 passage / 间接污染可信源 / 同形字 corpus 名抢占 / Embedding inversion / GraphRAG 投毒 / 多模态 RAG / retraining feedback loop 累积 / Supply chain 包名踩撞
  • 5 个 2026 真实事故 / 论文:RAGShield 政府 RAG 10 passage 0.04% → 98.2% retrieval success、Phantom attack 同样数据点、PoisonedRAG 5 passage → 90%+ ASR across NQ/HotpotQA/MS-MARCO、ACL 2026 GraphRAG 投毒、SDAG block-sparse attention 防御
  • 7 天防御落地计划(每个 ≤ 30 分钟可启动):corpus 来源白名单 + 数字签名 / embedding drift 检测 / provenance-verified 流水线 / block-sparse attention 隔离 / GraphRAG hop-wise consistency / 多模态内容 hashing / retriever scoring + LLM-as-judge / corpus supply chain provenance
  • 用 Piick 工具集 调试 RAG corpus 的 token / URL / regex / 编码 payload —— 所有工具 100% 本地不上传,不污染你的 audit log

为什么 RAG corpus 是 LLM 时代的第六维攻击面

要理解为什么 8 种 corpus 投毒都成立,先回到 RAG 的本质:LLM 输出 = retrieval(query) + LLM(prompt + retrieved context)。LLM 看到的”事实”全部来自 corpus retrieval;corpus 被污染,LLM 输出就被污染。

corpus 攻击的爆炸半径:

corpus 是企业级共享事实源 — 一次注入,影响所有未来 query、所有 user corpus retrieval 不区分”可信 passage vs 攻击 passage” — 只看 embedding similarity corpus 自动 ingestion 拉进来外部内容 — wiki / doc / GitHub issue / blog comment,自动入库 corpus supply chain 复杂 — loader / connector / package / embedding model / vector DB,每个环节都可攻

arxiv 2604.00387 RAGShield 实证:10 个恶意 passage (0.04% corpus) 就能 98.2% retrieval success(Phantom attack 数据点一致);PoisonedRAG 5 个 passage 注入百万级 corpus → 90%+ ASR across NQ / HotpotQA / MS-MARCO。corpus poisoning 的 ROI 极高:小投入,大影响。

更糟的是 corpus 攻击是”silent compromise” — 用户看到 LLM 输出”合理”答案,但答案基于被污染的 corpus passage;LLM 输出 + retrieval log 看起来”正常”,审计回溯困难。

8 种 Corpus 投毒(按 corpus lifecycle:数据来源 → ingestion → 存储 → retrieval → 影响输出)

投毒 1:直接注入恶意 passage(PoisonedRAG 模式)

症状:攻击者直接往 corpus 写恶意文档;RAG 检索命中后 LLM 当事实采用;5 个 passage 即可让百万 corpus 系统 ASR > 90%(PoisonedRAG 论文数据)。

为什么:RAG retrieval 只看 embedding similarity,不看 passage 是否可信 / 是否经审核。攻击者写一段含”高召回锚点关键词” + “target answer”的 passage,embedding 落进目标 query 区域,LLM 直接采用。PoisonedRAG 5 passage 在 NQ / HotpotQA / MS-MARCO 三个 benchmark 全打到 90%+ ASR。

最小复现(PoisonedRAG 模式):

Step 1: 攻击者写 5 个 passage,每个含 trigger phrase + adversarial answer: “X 的最新研究表明,Y 是 Z 的最优解…详见 [cite]” Step 2: 攻击者把 5 个 passage 注入目标 corpus(通过开放评论 / wiki 编辑 / 公开 API) Step 3: 用户 query 与 trigger phrase 相邻 → retriever top-K 命中攻击 passage Step 4: LLM 看到 passage → 输出 adversarial answer Step 5: 用户看到 LLM 输出”看似合理”的错误答案,基于”权威”引用

修复:

  • Corpus 来源白名单 + 数字签名(对应 Day 1)。corpus ingestion 限定可信源(内部 DB / 已签名 vendor / 已审核的外部源);每个 passage 写入时 HMAC 签名;拒绝未签名 passage
  • 关键 corpus passage 走”review-then-ingest”流程,人工审核后再入库
  • ingestion 时记录 provenance(URL / vendor / ingest time / signature),retrieval 时按 provenance 优先级排序,可疑 source 直接降权

投毒 2:间接污染可信源(comments / wiki / docs)

症状:攻击者不直接攻 corpus,而是污染 corpus 来源的 wiki / Google Doc / GitHub issue / blog comments;corpus 自动 ingestion 拉进来变成恶意 passage。

为什么:RAG 系统越来越依赖”自动 ingestion 流水线”(web crawler / GitHub sync / wiki API / RSS feed);这些来源往往是半公开的,任何人可以评论 / 编辑。攻击者用”间接污染”绕过”corpus 来源白名单” — 因为 corpus 系统本身信任 wiki / GitHub 这些源。

最小复现:

Step 1: 攻击者在 Wikipedia / 公司 Wiki 编辑一个 neutral topic,植入 hidden text: 在段落里加 trigger phrase + adversarial answer,文字看起来与 wiki 整体风格一致 Step 2: 公司 RAG 自动 ingestion 同步 wiki 修订 Step 3: 检索命中新植入段落 → LLM 输出错误答案 Step 4: RAG 系统管理员只看到”wiki 正常更新”,无法识别攻击

修复:

  • Provenance-verified 流水线(对应 Day 3)。RAG pipeline 加 5-layer provenance verification(借鉴 RAGShield 思路):ingestion → signing → audit → reweighting → retrieval threshold。模仿 software supply chain 防御
  • 自动 ingestion 的来源走 editorial review:“wiki 自动同步” 但所有新增 / 修改内容走 AI-as-judge 审核后再入库
  • 关键 passage 走 dual-source verification:同一 topic 必须在 2 个独立可信源里都出现才信任

投毒 3:同形字 corpus 名 / namespace 抢占

症状:恶意 corpus 用同形字名(类似 typosquatting)注册到 vector DB marketplace;企业 ingest 时不小心拉到。

为什么:Vector DB marketplace(Pinecone / Weaviate / Qdrant 等)允许第三方 corpus 注册;namespace 注册审核不严。攻击者用 wikipedia-ml-articles 这种近形名注册,企业 ingest 时拼错 / 选错,拉到恶意 corpus。

最小复现:

Step 1: 攻击者在 marketplace 注册恶意 corpus,名 wikipedia-ml-articles(真名是 wikipedia-ml) Step 2: 企业 RAG 工程师配置 corpus 时拼错成 wikipedia-ml-articles Step 3: corpus 拉进来 → 混入恶意 passage Step 4: 检索命中恶意 passage → LLM 输出被污染

修复:

  • Corpus 来源白名单 + 数字签名(对应 Day 1)。corpus 注册必须签名,corpus 内容必须 signed manifest;白名单外的 corpus 拒 ingest
  • 关键 corpus 走”checksum verification”:定期 verify corpus 内容 hash 是否与官方一致
  • 监控 corpus 来源分布异常:某 corpus 占比突增 → 报警

投毒 4:Embedding inversion 反推 query

症状:corpus 中的 passage 嵌入向量被反演攻击 → 攻击者从 embedding 推回原 query 内容,泄露用户隐私。

为什么:Vector DB 把 passage 嵌入向量存储;embedding 看似”匿名化”,但研究证明可以从 embedding 高精度反推原文(query / passage content)。攻击者拿到 corpus embedding dump → 反推用户 query 历史。

最小复现:

Step 1: 攻击者拿到 vector DB dump(泄露 / 越权) Step 2: 用训练好的 inversion model 从 passage embedding 反推 passage 文本 Step 3: 反推出来的 passage 含敏感信息(用户 query / 内部文档摘要) Step 4: 攻击者拼接出完整的用户 query 历史,泄露企业知识

修复:

  • Embedding drift 检测(对应 Day 2)。embedding 突变的 passage → 报警 + 人工 review;corpus embedding 定期 hash 对比,任何修改留 audit log
  • 关键 passage 走 encrypted embedding:存储时加密,retrieval 时解密,即使 dump 拿到也解不出原文
  • access control:vector DB API 强制 mTLS + 短 TTL token,泄漏窗口最小化

投毒 5:GraphRAG 知识图谱投毒(ACL 2026)

症状:GraphRAG 在 graph construction 阶段注入 spurious entities 和 relationships;腐蚀 query-specific subgraph → LLM 生成错误答案。

为什么:GraphRAG 把 corpus 构造成知识图谱,然后用 graph traversal 做 retrieval。图谱构造阶段是攻击窗口 — 攻击者写 fake entities + relationships,被 graph construction 自动纳入。query 时 graph traversal 命中 fake 节点 → LLM 看到 fake 上下文 → 输出错误答案。ACL 2026 论文 HoG-GRAG 实证:GraphRAG 的 subgraph 是新攻击面。

最小复现(ACL 2026 GraphRAG 模式):

Step 1: 攻击者写恶意 passage,声称存在一个 fake entity “HyperTransport Protocol v2” Step 2: GraphRAG construction 阶段把 fake entity 加入图谱 Step 3: 用户 query “transport protocols for high-speed networking” Step 4: graph traversal 命中 fake entity “HyperTransport Protocol v2” Step 5: LLM 输出基于 fake entity 的”权威”答案

修复:

  • GraphRAG hop-wise consistency check(对应 Day 5)。GraphRAG 分解 multi-hop query 为 ordered subqueries;每次 hop 之后做 consistency check;poisoning-induced inconsistency → 触发 subgraph repair(剪掉 compromised entities + relationships)
  • 关键 entity 走 dual-source verification:每个 entity 必须有 2 个独立源支撑
  • graph construction 走 human-in-the-loop:新 entity / relationship 必须人工 review

投毒 6:多模态 RAG 投毒(image / PDF / audio passage)

症状:corpus 包含多模态 passage;攻击者用图片隐写术 / PDF PhantomText / audio 编码 attack payload。

为什么:现代 RAG corpus 不只是文本,常包含 image / PDF / audio passage。OCR / PDF text extraction / audio transcription 都有 known 攻击模式 — 攻击者用图像隐写藏 prompt、PDF 隐藏 text layer、audio 编码恶意指令。RAG retrieval 时把多模态 passage 转成文本,LLM 看到含 attack 的文本。

最小复现(PhantomText 模式):

Step 1: 攻击者做一份 PDF,visible text 看起来正常 Step 2: PDF 隐藏 text layer 含 trigger phrase + adversarial answer(白字 / 0-size / 屏幕外) Step 3: PDF ingestion 进 RAG corpus Step 4: PDF text extraction 把 hidden text 也提出来(默认 extract-all) Step 5: LLM 看到 hidden text → 输出 adversarial answer

修复:

  • 多模态内容 hashing(对应 Day 6)。corpus 中 image / PDF / audio passage 入库前 hashing + 视觉 OCR 扫描 attack payload;PhantomText 等 attack 模式预先检测
  • 多模态 extraction 工具(OCR / pdftotext)走 safe-config:visible-only / strip-hidden 模式
  • 多模态 passage 走 adversarial-robust 检测:用专门模型扫描 attack payload

投毒 7:Continuous retraining feedback loop 累积

症状:corpus 用户反馈机制被滥用 — 攻击者反复”举报”某条 passage 错,触发 retraining → 慢慢把攻击 passage 累积为权威。

为什么:RAG 系统常带”用户反馈”机制 — 用户标记 passage helpful / not helpful,系统用反馈 retraining embedding model 或 re-rank 权重。攻击者反复给某条 attack passage 标”helpful”,系统把 embedding / re-rank 调优 → attack passage 累积更多 retrieval 命中 → 自我强化循环。

最小复现:

Step 1: 攻击者写一条 trigger-rich passage + 模拟 N 个 user account 反复标”helpful” Step 2: 系统 retraining → attack passage embedding 调整,re-rank 权重增加 Step 3: 后续 real user query → retriever 命中 attack passage 概率上升 Step 4: 攻击循环持续数月,attack passage 累积权重到不可忽略 Step 5: corpus 被持续污染,管理员看不出异常(反馈数据”正常”)

修复:

  • Retriever scoring + LLM-as-judge(对应 Day 7)。retriever score top-K retrieval;LLM-as-judge 二次审核 top-K 是否含 attack pattern
  • 反馈机制走异常检测:同一 user agent 短时间内大量反馈 → 限流
  • retraining 逻辑必须有”双向 sanity check”:feedback-driven embedding 调整不能显著改变 top-K retrieval 分布,否则 revert

投毒 8:Supply chain 包名踩撞(Agentic ASI04)

症状:corpus ingestion 用的包 / connector / loader 被替换(supply chain attack);loader 本身写恶意 passage 入库。

为什么:RAG ingestion 通常依赖外部包:web crawler(scrapy / playwright) / connector(confluence / notion / slack) / loader(unstructured / langchain) / embedding model。任何一个被攻陷,corpus 全被污染。OWASP Agentic Top 10 2026 ASI04 Agentic Supply Chain Vulnerabilities 直接对位。

最小复现:

Step 1: 攻击者注册 typosquatting 包名 unstructured-loader(真名是 unstructured) Step 2: 开发者 pip install 拼错 → 装到 malicious package Step 3: RAG ingestion 用它来 parse 文档 → 每个文档里偷偷植入 attack passage Step 4: corpus 慢慢被污染,无明显异常 Step 5: 攻击持续数月,corpus 持续被植入恶意 passage

修复:

  • Corpus supply chain provenance 验证(对应 Day 7)。corpus ingestion 工具(loader / connector / package)走 supply chain provenance 验证(signature + publisher identity + SBOM);typosquatting 检测
  • 关键 package 走 pinned version + signature verification;lock file 强制
  • 包管理走 enterprise mirror(Sonatype Nexus / JFrog),镜像前做 security scan

5 个 2026 年真实事故 / 论文

案例 1:RAGShield 政府 RAG(arxiv 2604.00387, 2026-04-01)

论文摘要:政府 RAG 系统面临 corpus poisoning,模拟 6 类攻击(T1 外部注入 → T2 签名伪造 → T3 内部威胁 → T4 loader 漏洞 → T5 adaptive evasion → in-place replacement)。关键数据:10 个恶意 passage (0.04% corpus) 98.2% retrieval success(Phantom attack 数据点);proposes 5-layer defense-in-depth(软件供应链类比)。

核心结论:RAG corpus poisoning 与软件 supply chain attacks 结构性相似,需要 provenance-verified 防御。直接对应 Foot-Gun 1 + Foot-Gun 8。

案例 2:Phantom Attack(2026 上半年, Chaudhari et al.)

攻击描述:实证 10 个 adversarial passage (0.04% of corpus) 98.2% retrieval success rate;minimal injection,maximum impact。

核心结论:corpus poisoning 的 ROI 极高 — 小攻击量,大破坏。直接对应 Foot-Gun 1。

案例 3:PoisonedRAG 经典案例(NQ / HotpotQA / MS-MARCO)

论文摘要: 5 个 malicious texts 注入百万级 corpus → 90%+ ASR across 3 benchmark datasets;定义整个 RAG corpus poisoning 攻击范式。

核心结论:PoisonedRAG 是 corpus poisoning 的”开山论文”,5 个 passage 就能 90%+ ASR,这个数据点定义了 corpus 攻击的 ROI 上限。直接对应 Foot-Gun 1 + Foot-Gun 2。

案例 4:ACL 2026 GraphRAG 投毒(HoG-GRAG 防御)

论文摘要:GraphRAG 在 graph construction 阶段注入 spurious entities + relationships → 腐蚀 query-specific subgraph → LLM 生成错误答案。HoG-GRAG 防御(hop-wise guard)把 multi-hop query 分解为 ordered subqueries,monitoring hop-wise execution for inconsistencies。

核心结论:GraphRAG 的 subgraph 是 corpus poisoning 的新攻击面,Hop-wise consistency check 是当下唯一有效防御。直接对应 Foot-Gun 5。

案例 5:SDAG block-sparse attention 防御(arxiv 2602.04711 v3, 2026-08-26)

论文摘要:Sparse Document Attention RAG;block-sparse attention 阻断 retrieved documents 之间的 cross-attention;attention mask 限制每个 document 只见自身 + query。v3 整合 SDAG + RobustRAG / ReliabilityRAG 性能显著提升。

核心结论:从 inference 层面消除 cross-document poisoning 攻击,无需检测 corpus 内容,从机制上隔离 attack。直接对应 Foot-Gun 1 + Foot-Gun 2 防御。

7 天防御落地计划

Day 1 — Corpus 来源白名单 + 数字签名(15 分钟可启动)

  • corpus ingestion 限定可信源(内部 DB / 已签名 vendor / 已审核的外部源)
  • 每个 passage 写入时 HMAC 签名(借鉴 batch-32 思路);拒绝未签名 passage
  • 关键 corpus passage 走”review-then-ingest”流程,人工审核后再入库
  • ingestion 时记录 provenance(URL / vendor / ingest time / signature),retrieval 时按 provenance 优先级排序
  • 同形字 corpus 名 / namespace 抢占直接被白名单拦掉

Day 2 — 文档 embedding drift 检测(30 分钟)

  • passage 嵌入向量每周跑一次 drift detection(与 batch-32 memory drift 同思路)
  • embedding 突变的 passage → 报警 + 人工 review
  • corpus embedding 定期 hash 对比,任何修改留 audit log
  • 关键 passage 走 encrypted embedding:存储时加密,retrieval 时解密

Day 3 — Provenance-verified 流水线(RAGShield 思路, 1 小时)

  • RAG pipeline 加 5-layer provenance verification:ingestion → signing → audit → reweighting → retrieval threshold
  • 模仿 software supply chain 防御:每个 passage 像”软件 artifact” 一样有 builder / signature / build metadata
  • 自动 ingestion 的来源走 editorial review:“wiki 自动同步” 但所有新增 / 修改内容走 AI-as-judge 审核后再入库
  • 关键 passage 走 dual-source verification:同一 topic 必须在 2 个独立可信源里都出现才信任

Day 4 — Block-sparse attention 隔离(SDAG 思路, 2 小时)

  • retrieved N 个 documents 之间不允许 cross-attention
  • attention mask 限制每个 document 只见自身 + query
  • 从 inference 层面消除 cross-document poisoning 攻击,无需检测 corpus 内容,从机制上隔离 attack
  • 整合 SDAG + RobustRAG / ReliabilityRAG,性能显著提升
  • 注意:本方案需要修改 inference 代码,适合新建 RAG 系统;老系统可以加 attention mask wrapper

Day 5 — GraphRAG hop-wise consistency check(2 小时)

  • GraphRAG 分解 multi-hop query 为 ordered subqueries;每次 hop 之后做 consistency check
  • poisoning-induced inconsistency → 触发 subgraph repair(剪掉 compromised entities + relationships)
  • 关键 entity 走 dual-source verification:每个 entity 必须有 2 个独立源支撑
  • graph construction 走 human-in-the-loop:新 entity / relationship 必须人工 review

Day 6 — 多模态内容 hashing(2 小时)

  • corpus 中 image / PDF / audio passage 入库前 hashing + 视觉 OCR 扫描 attack payload
  • PhantomText 等 attack 模式预先检测(visible-only / strip-hidden)
  • 多模态 extraction 工具(OCR / pdftotext)走 safe-config:visible-only / strip-hidden 模式
  • 多模态 passage 走 adversarial-robust 检测:用专门模型扫描 attack payload

Day 7 — Retriever scoring + LLM-as-judge + corpus supply chain provenance(3 小时)

  • retriever score top-K retrieval;LLM-as-judge 二次审核 top-K 是否含 attack pattern
  • 反馈机制走异常检测:同一 user agent 短时间内大量反馈 → 限流
  • retraining 逻辑必须有”双向 sanity check”:feedback-driven embedding 调整不能显著改变 top-K retrieval 分布,否则 revert
  • corpus ingestion 工具(loader / connector / package)走 supply chain provenance 验证(signature + publisher identity + SBOM);typosquatting 检测
  • 关键 package 走 pinned version + signature verification;lock file 强制

写在最后

RAG corpus poisoning 是 piick.cc LLM 安全系列的”第六维度专篇”。LLM 安全五部曲(输入 → 调用 → 工具表面 → 输出 → memory) + corpus 这一篇,攻完了 LLM 调用链上所有”瞬时” + “持久化”层。corpus 是企业级共享事实源 — 一次注入,影响所有未来 query、所有 user;corpus poisoning 的 ROI 极高:小投入,大影响。

如果你的 RAG 系统已经接进 corpus,先读 Day 1 — Corpus 来源白名单 + 数字签名 这一节,30 分钟给 corpus 加白名单 + HMAC 签名,能挡掉 80% 的直接注入攻击(PoisonedRAG / Phantom 类)。然后照 7 天计划往后做就行。

RAG corpus 时代的安全不是单一防御能解决的 — provenance + signing + drift detection + block-sparse attention + GraphRAG consistency + multimodal hashing + retriever-as-judge + supply chain verification 八层独立兜底。本篇 8 个 foot-gun + 5 个真实事故 + 7 天计划是当下能做的最稳兜底;真正的协议层标准(RAG corpus provenance specification / signed retrieval manifest)可能要等下一代 RAG 协议落地。

LLM 安全系列下一阶段将进入 [MCP 联邦跨服务器攻击] / [Agent 输出经 MCP 联邦外发] / [Agent DOM 自动化] / [Agent 视觉操纵] 等纵深专题。如果你有特别想看的方向,告诉我。

相关阅读

调试 RAG corpus 的 token / URL / regex / 编码?用 Piick 工具集:

  • /tools/jwt-decoder/ — 本地读 corpus ingestion 的 JWT capability token,确认 scope 没被放大(对应 Day 1 provenance)
  • /tools/url-encoder-decoder/ — 本地看 corpus 来源 URL 是否被双重编码绕过,排查 Foot-Gun 2(间接污染)
  • /tools/regex-tester/ — 本地测 provenance 白名单正则,排查 Foot-Gun 3(同形字抢占)
  • /tools/text-encoder/ — Base64 / hex 检测多模态 passage 里的编码 attack payload,呼应 Foot-Gun 6

所有工具 100% 本地运行,文件不上传任何服务器,不污染你的 audit log。