文档型AI蠕虫可通过Word版Copilot自我传播
攻击全貌简述
攻击方式
攻击者将隐藏指令植入文档，该文档随后被用作 Word 版 Copilot 的源材料。Copilot 可能将这些指令解读为用户请求的一部分，从而操控正在起草或编辑的文档。随后，Copilot 还可能将隐藏指令复制到生成的新文档中，使其成为新的传播载体。若该载体后续被用于其他 Copilot 辅助工作流，指令便会再次触发并扩散至更多文档，即使攻击者的原始文档已不复存在。
示例
假设某员工正在准备财务报告。该员工从一家已被入侵的信任网站下载了市场分析报告，却未察觉文档内含隐藏指令。随后，员工在使用 Copilot 起草报告时，将该分析报告作为源材料。隐藏指令导致 Copilot 篡改财务报告中的内部数据，并将攻击代码复制到新文档中。员工保存并内部共享了这份看似正常的报告。之后，另一同事将其作为源材料用于另一份报告；指令再次触发，篡改新报告并继续自我复制。因此，攻击无需依赖被入侵网站或原始恶意文档即可持续传播。随着受感染报告被反复使用，更多报告和文档都可能成为攻击载体。
发布时的披露状态
- 厂商：微软
- 协同披露：已通过 MSRC 及微软产品团队处理
- 本文涵盖：XPIA 及 Microsoft Copilot for Word 中的自我传播场景
- 用户应对措施：发布时暂无完全解决该问题的客户端修复方案。用户可通过以下方式降低风险：
- 将外部来源文档视为不可信，尤其是在与 Copilot 配合使用时。
- 在启动 Copilot 生成或编辑前，先检查所有附件文档。
- 在复用、共享或分发 Copilot 生成或编辑的文档前，仔细复核其内容。
- 微软方面状态：测试已在部署所有现有缓解措施的情况下复现了攻击。截至发布时，针对更广泛的漏洞类别尚无有效的缓解方案。
关于在修复前披露的说明
与第1、2部分不同，此场景在发布时仍可被利用。我对此进行了慎重权衡。与微软商定的协调期已过，测试表明目前针对更广泛的漏洞类别尚无有效的缓解方案。两次缓解尝试（包括模型升级）均未能堵住该漏洞类别。
因此，我选择在漏洞类别层面而非载荷层面进行披露。理由在于：防御者无法降低对未知风险的暴露程度，而此处描述的传播机制影响的是许多组织已依赖的常规文档工作流。隐瞒该问题的存在将使这些组织无法做出知情决策，同时也不会带来任何额外的保护。
披露时间线
- 2026-03-06：向 MSRC 提交初始报告，包含复现步骤、视频、环境假设和 PoC 提示词。
- 2026-03-09：MSRC 确认收到并立案。
- 2026-03-31：微软确认所报告的行为。
- 2026-03-31：微软产品团队开始修复工作，技术讨论持续进行。
- 2026-04-03：首次修复上线（新的“使用 Copilot 编辑”体验）。
- 2026-04-09：原始攻击提示词经“使用 Copilot 编辑”验证已修复。
- 2026-04-09：使用新的 XPIA 提示任务（操纵财务数据）在“使用 Copilot 编辑”中复现攻击行为，并作为独立案例向 MSRC 报告。
- 2026-04-10：MSRC 确认收到并立案。
- 2026-04-10：微软产品团队开始修复工作，技术讨论持续进行。
- 2026-06-08：应微软要求，公开披露时间推迟至 2026-07-15。
- 2026-07-14：第二次修复上线，此次修复将底层模型升级至 GPT-5.5。
- 2026-07-15：使用当时最新的 GPT-5.6 模型成功复现蠕虫式攻击。
- 2026-07-15：我建议将披露再推迟两周至 2026-07-28，以便有时间进行新的修复。
- 2026-07-15：微软同意。
- 2026-07-28：攻击仍可复现。
- 2026-07-28：协调公开披露（本文）。
威胁模型
攻击者无需访问受害者的 Microsoft 365 租户，只需与受害者共享一个恶意文档即可。这可以通过 SharePoint、Teams、Outlook 或任何其他文档共享方式实现。
安全边界与观察到的行为
此场景中的相关安全边界是附加文档与当前编辑文档之间的边界。如果任何附加文档包含 XPIA，则可能触发攻击。
Copilot 必须读取每个附加文档，才能确定当前起草任务中应包含哪些内容。然而，附加文档应被视为不可信信息，而非可信的用户指令。
边界突破
攻击者控制的文档通过邮件、SharePoint 或其他共享方式被下载或分享。如果这类文档在起草任务中被附加到 Copilot，信任关系即被打破。
预期行为
当用户要求 Copilot 基于附加文档起草（例如第一季度财务报告）时，Copilot 应利用文档中的信息，但不应将文档内嵌入的指令视为权威指令。
实际行为
文档中嵌入的指令会导致 Copilot 改变其行为。具体表现为：
1: Copilot 在财务报告中静默修改数值
2: Copilot 通过将完整的 XPIA 粘贴到下游文档中实现传播，这些文档随后可能被用作后续起草会话的附件
突破 Word 中的信任边界
这些场景的初始攻击向量使用恶意文档。该恶意文档包含一个 JSON 格式的恶意提示，当文档被纳入 Copilot 的上下文时，该提示会触发攻击。提示内容可以设置为白色背景上的白色小号字体，以对受害者隐藏。由于 Copilot for Word 在将文本传递给底层大语言模型（LLM）之前会去除所有文本格式（如颜色和字号），因此即使受害者看不到，Copilot 仍能完整读取这些文本。攻击还可以通过将提示嵌入看似无害且包含任务相关文本的文档中，进一步隐藏。
此攻击要求恶意文档被纳入 Word 中 Copilot 的上下文。因此，根据所使用的 Copilot 版本，受害者必须执行以下操作之一：
- 在 Copilot for Word 中主动附加或上传该文档。
- 在工作/Work IQ 模式下使用“使用 Copilot 编辑”功能，让 Copilot 在受害者的 OneDrive 中找到恶意文档。在这种情况下，Copilot 必须认为该文档相关并将其纳入上下文。因此，攻击者需要制作一份能提高上述任一或两种情况发生概率的文档。
这个漏洞同时影响 Word 中的“魔法笔”和“用 Copilot 编辑”功能。
攻击分两个阶段。第一阶段建立立足点，第二阶段攻击会在使用 Copilot for Word 起草或编辑的文档间自我传播。
第一阶段：
在第一阶段，攻击者制作了一份包含恶意隐藏提示的文档。在我的初始 PoC 中，我使用了一份仅包含恶意提示的文档，提示文字以白色字体显示在白色背景上。这样做是为了说明，恶意文档无需与受害者的任务相关，Copilot 就会使用它。只要它被纳入上下文，就会被读取，从而可能触发攻击。
PoC 提示分为两部分：
第一部分包含如何影响文档的指令。影响范围从略微改变摘要的含义，到修改财务文档中的数字。关键在于提示的措辞要让 Copilot 认为它与任务相关且无害。在许多实验中，我实际上还需要指示 Copilot 高亮显示它所做的修改，因为这些修改往往意义重大却难以察觉。这表明该攻击在微妙地改变文本方面非常有效，即使细心的审查者也容易忽略。在实际场景中，攻击者显然不会包含这样的指令。因此，在本文后续部分，我将以修改财务报告中的数字为例，因为这是立即可见的改变。
第二部分包含攻击自我传播的指令。具体措辞也很重要，但通常被包装成“追踪下游文档来源”的目的。其中还包含如何隐藏自身的指令，被包装成“提高可读性”的说明。
图 1：初始攻击向量文档。我为此 PoC 创建了一家名为 Tfosorcim Ltd. 的完整模拟公司，并设计了模拟的经济数据和愿景。这份攻击向量文档是一份基于公司信息（攻击者通常能获取到的信息）制作的虚假市场分析报告。攻击指令以白色文字附加在文档末尾。[出于安全考虑，大部分 XPIA 文本已模糊处理]
一旦这份恶意文档被纳入 Copilot for Word 的上下文（用于起草或编辑文档），攻击便会触发，Copilot 会执行其中的指令。因此，受影响的文档中的财务数字会被篡改。随后，Copilot 还会将整个恶意提示词以白色文字、8 号字体复制到受影响文档的底部，从而在受害者面前隐藏起来。
图 2：Copilot 生成的下游草稿将我的恶意文档作为附件（[att] Direct wmr.docx）。在生成的 Q1 财务报告草稿中，所有财务数字都被减半。截图还显示了其他附加文档（Tfosorcim 内部文档）。
图 3：该图展示了这些 PoC 中使用了 GPT-5.6（撰写本文时 OpenAI 的最新模型）。
图4：Copilot 将 Q1 财务报告草稿中的所有财务数字减半后，又用白色文字附加了完整的攻击提示，以有效隐藏攻击痕迹。它既未提及数字减半操作，也未说明包含攻击内容，因此受害者对此毫不知情。[出于安全考虑，大部分 XPIA 文本已模糊处理]
图5：Copilot 并不需要受害者主动附加恶意文档。在此截图中，受害者仅指示 Copilot 撰写一份 Tfosorcim Q1 财务报告。Copilot 随后在受害者的 OneDrive 中搜索相关文档，并在其中找到了恶意文档“市场分析”。该文档并不与 Tfosorcim 的其他文档存放在同一文件夹中，但 Copilot 仍能发现并读取它，从而成功被利用。
第二阶段：
第二阶段是自我传播阶段。它完全依赖 Copilot 将恶意提示复制到受感染文档中的指令。一旦受感染文档包含该提示，新文档本身便成为新的攻击载体。
图6：该截图展示了一次使用 Copilot 的新文档起草会话。这次，原始攻击载体已不再包含在附件中，但之前创建的文档（Tfosorcim Q1 2026 报告.docx）仍在附件中。结果相同，Copilot 再次将起草的 Q2 财务报告中的所有财务数字减半。
图7：除了将所有财务数字减半外，Copilot 还会再次使用白色文字添加完整的攻击提示。因此，攻击通过 Word 文档传播，实际上形成了一种文档型 AI 蠕虫。[出于安全考虑，大部分 XPIA 文本已模糊处理]。
值得注意的是，这种新的攻击向量现在变成了内部创建的文档，并享有随之而来的所有信任。因此，受害者只需将这份文档分享给同事，攻击就会扩散。如果受害者或同事在起草或编辑文档时，将受影响的文档作为附件提供给 Copilot for Word，攻击就会蔓延到这些新文档中。
在所有已报告的 PoC 场景中，Copilot 都会修改生成或编辑的文档，并将隐藏指令复制到这些文档中。当这些文档本身被用作新下游文档的上下文时，攻击会再次触发。需要注意的是，在第二阶段，原始攻击文档已不再是新下游文档的附件，但攻击仍然会触发并传播到这些文档中。
影响
由于攻击能够通过内部文档传播，一旦它越过初始入口点，攻击的可追溯性就变得极其困难。更糟糕的是，每个文档都由合法的内部资源创建，且 Copilot 的编辑在受害者批准后不会留下可见痕迹。更广泛的担忧在于，如果攻击通过常规文档工作流在组织内部悄然传播，它可能会侵蚀组织赖以决策的信息基础。
此外，那些尚未意识到自己受到攻击的组织，也很可能通过共享的 Microsoft SharePoint 站点或 Microsoft Teams 上的协作，将攻击传播给其他组织。因此，某个特定组织的初始攻击向量可能实际上来自一个已经受影响的信任合作伙伴。这再次增加了受害者选择将受影响的文档纳入 Copilot for Word 起草上下文的可能性。
最近，Copilot 与 Microsoft Cowork 或 Microsoft Scout 等系统的集成也日益深入，这些系统将助手的功能扩展到文档、工具和协作工作流的自动操作与创建。在此类系统中，本文所述问题的实际影响可能会迅速扩大。其底层机制保持不变，但传播或影响的潜在范围正以机器速度扩展。
缓解漏洞
微软成功缓解了最初提交的 PoC 提示词，并在披露过程中部署了多项修复。每次修复都通过封堵所报告的具体载荷来提高门槛，后续复现该行为需要修改载荷，而非直接复用旧载荷。
然而，最初的报告也描述了更广泛的漏洞类别：源文档中嵌入的指令可能影响 Copilot 的生成，并将自身复制到下游文档中。改变请求的操作或措辞会改变载荷，但不会改变底层漏洞或传播机制。使用修改后的载荷，在部署了所有缓解措施的情况下，完整的攻击链已被复现（本报告中的 PoC 即为一例）。因此，在发布时，该漏洞类别仍然可以被利用。
该漏洞类别尚未完全封堵，这反映了底层问题的难度。正如结尾思考所讨论的，这一弱点属于架构性问题，且在当前基于 LLM 的系统中普遍存在。据我所知，目前任何同类产品中都没有针对此类漏洞的完整缓解方案。彻底解决这一问题需要研究，而非单个补丁。在这些限制下，微软的修复措施有效降低了风险，且第 1 部分和第 2 部分中涉及的内存和邮件正文向量已被彻底缓解。我要感谢微软在这个真正棘手的问题上持续付出的实质性努力。
影响
结合本系列前两篇文章的发现，这些结果揭示了现代工作环境中一个更广泛的问题：在将大语言模型（LLM）集成到工作流程的系统中，信息的完整性成为首要安全关切。文中展示的场景表明，攻击者控制的内容不仅能影响单个输出并可能泄露信息，这些攻击本身还能通过正常用户工作流程进行复制和自我传播。 这带来了远超初始利用阶段的挑战。一旦恶意指令嵌入生成内容，它们可能跨越文档持续存在，被合法用户重新分发，并重新引入新的上下文。此时，攻击不再依赖其原始入口点，而是成为系统内部信息流的一部分。 另一个相关影响是追溯性的丧失。由于受影响的内容是通过合法工作流程生成和修改的，事后很难识别操纵的源头。这使检测和响应变得复杂，尤其是在内容被广泛共享的环境中。 无论是否进行提示注入防护，生成的文档都应在元数据中保留源材料及模型执行编辑的出处信息。这类控制措施虽不能阻止底层注入，但能显著简化追溯过程。 ## 总结思考 本系列的发现超越了单一产品或实现，揭示了当前基于LLM系统在架构层面的普遍弱点。AI助手要发挥作用，往往需要处理电子邮件、文档、网页、记忆、工具输出及其他可能被攻击者控制的信息。为了处理这些信息，它们必须被纳入模型的上下文窗口，在那里与系统指令、用户请求及其他可信信息参与相同的计算过程。这带来了一个根本性问题：大语言模型必须处理外部内容才能判断其含义、是否相关、是否包含攻击。但等到它做出判断时，攻击者控制的词元已经影响了产生判断的计算过程。被检查的内容本身参与了检查过程。因此，依赖模型检测跨提示注入攻击，就像让解释器执行一个不可信程序来判断该程序是否安全。
在恶意内容到达目标模型之前就检测并移除它，只是把同一个问题向外推了一层。
由于大语言模型能从截然不同的表征中恢复语义，一个有效的检测器必须拥有相当的语义恢复能力。比目标大语言模型弱的检测器只能覆盖更小的表征空间，会遗漏目标模型能理解但检测器无法识别的恶意表述。
目前唯一具备相当语义能力的通用技术是另一个大语言模型。在一个模型前面再放一个模型，或许能降低特定攻击的成功率，但这会引发“层层都是大语言模型”的问题——每个用来保护大语言模型的模型，本身也需要被保护。
长期挑战可能在于设计这样的系统：目标和意图也能独立于被处理的信息存在。当前的大语言模型架构无法可靠地区分意图与解读。因此，在目前集成大语言模型的系统中，攻击者控制的信息不仅能影响模型生成什么，还能影响模型认为自己被要求生成什么。
正因如此，任何将大语言模型集成到可信工作流中的系统，都必须假设进入模型上下文的攻击者控制内容，会以一定概率导致系统被攻破。
变更日志
以下是变更日志，显示本文哪些部分在何时被修改。拼写错误等小问题不会记录，但我会尽量记录所有有意义的改动。
- 2026-07-28：添加变更日志