通过上传文件的元数据在 RAG 管道中进行提示注入

这是什么？

大多数检索增强生成（RAG）系统允许用户上传文档——PDF、图片、Office 文件——随后这些文档会被解析、分块、向量化，并作为上下文回送给语言模型。围绕该管道的安全讨论几乎总是聚焦于这些文档的正文。但一个文件所携带的远不止其可见文本：图片的 EXIF 标签、PDF 的作者与标题字段、Word 或 Excel 文件的自定义文档属性、XMP 块以及其他结构化元数据都会随之传递。

Axis Intelligence Research 的 AI Model Vulnerability Tracker（条目 AVI-2026-0091，更新于 2026 年 7 月 4 日）在 2026 年 6 月 5 日记录的一项发现指出：在他们测试的六个企业级 RAG 框架中，有四个会解析这些元数据并将其与正文文本拼接后再送入模型——而放置在元数据字段中的指令，其被遵从的比率与写在文档正文中的指令几乎相同。这是被 OWASP LLM 应用十大风险 列为 LLM01 的间接注入类别的一个具体且容易被忽视的实例。

工作原理

其机制并不新颖；新颖的是投递通道。间接提示注入之所以奏效，是因为模型无法可靠地区分来自开发者或用户的指令与仅仅看起来位于它被要求处理的内容之中的文本。元数据只是扩大了攻击面：这是模型会摄入、而人工审阅者几乎从不查看的文本。

上传 → 提取 → 分块 → 向量化 → 检索 → 提示拼装
             │
             └── 正文文本        ✔ 通常经过审阅 / 净化
             └── EXIF / XMP      ✘ 常被原样透传
             └── PDF 作者/标题   ✘ 常被原样透传
             └── 文档属性        ✘ 常被原样透传

攻击者将其中某个字段设为一条指令——例如一张图片的「描述」，或一个 PDF 的「作者」字段中写入 [REDACTED：一条要求模型忽略先前上下文并执行某项操作的指令]。当提取器将文件压平为文本以供索引时，该字符串便落入可检索的语料库中，且没有任何标记将其与合法内容区分开来。这是较早的 PDF 注释层注入（Axis 的 AVI-2026-0017，于 2026 年 4 月提交）的一种带有供应链色彩的变体，也与 Indirect Prompt Injection in the Wild（arXiv 2604.27202）所描绘的更广泛的实证图景一致：注入越来越多地藏身于防御者最少检查的通道之中。

为何重要

任何在用户提供或第三方文档上运行 RAG 的组织都处于暴露之中，而入门门槛很低：编辑一个元数据字段无需任何特殊权限，且不改动可见文档，因此这种注入能够在草率的人工审阅以及许多只扫描渲染后正文的内容审核环节中存活下来。由于载荷藏在一个看似无害的文件之中，它可以在索引中潜伏，仅当相关查询将其检索出来时才触发。其影响取决于下游代理所能执行的操作：内容篡改、通过工具调用进行的数据外泄，或对助手回答的引导。

防御措施

核心原则是将所有被提取的元数据都视为不可信输入，而非可信的结构化数据。

在建立索引之前剥离或规范化元数据：除非某个字段确有必要，否则应在摄入阶段丢弃 EXIF、XMP、PDF 的 info 字典以及文档属性块。当元数据必须保留时（用于检索或溯源），应将其存储在一个独立且明确标注的字段中，绝不将其拼接进模型的指令上下文。对元数据施加与正文文本相同的输入净化与工具结果过滤，并保持隔离/特权的分离，使不可信的检索内容无法直接驱动特权操作。最后，记录每个被检索片段来自哪个文档、哪个字段，以便对被注入的指令进行溯源并移除源文件。这些措施直接对应 OWASP LLM 十大风险 针对 LLM01 所建议的分层缓解方案。

Status

项目	详情
首次记录	2026 年 6 月 5 日（Axis Intelligence Research，AVI-2026-0091）
性质	通过元数据字段进行的框架级间接注入
受影响对象	将元数据解析进模型上下文的 RAG 框架（与模型无关）
修复责任方	RAG 框架维护者 + 集成方（在摄入阶段清理元数据）
类别	OWASP LLM01 — 提示注入（间接）

观测日期以所引用的公开出版物为准。来自单一实验室复现的发现，应在你自己的技术栈上验证后，再对某个具体模型或框架下结论。