Copilot文档病毒可自传播，AI工具安全告急

首先，我要感谢 Microsoft 产品团队和 Microsoft 安全响应中心（MSRC）与我合作，对披露的漏洞进行技术分析并采取缓解措施。下文表达的编辑观点仅代表作者本人，并不一定反映与我合作的组织的立场。

本文介绍的发现是与 MSRC 及 Microsoft 产品团队协调披露的一部分。我向 Microsoft 提供了复现步骤、视频、环境假设，以及测试期间使用的完整概念验证（PoC）提示词。他们还获知，披露前将有 90 天的协调期。该期限后来延长了两次，最终协调期共计 144 天。

在本系列的第 1 部分和第 2 部分中，我展示了外部输入如何影响 Copilot 的响应，以及在某些情况下，如何通过跨域提示词注入攻击（XPIA）潜在地影响机密性。本报告以这些发现为基础，将 XPIA 分析从单次交互遭到入侵，扩展至攻击在受信任文档工作流中的传播。报告表明，一份文档中由攻击者控制的指令可能被复制到 Copilot 生成或编辑的 Word 文档中，使这些下游文档成为同一攻击的新载体。

此前已经出现过 AI 蠕虫的案例。尤其值得一提的是，Morris II 展示了在由生成式 AI 驱动的电子邮件助手生态系统中，提示词自我复制与传播的能力。不过，据我所知，这是首批公开演示之一，展示了文档携带的 AI 蠕虫如何通过主流商业生产力套件中的常规工作流实现自我传播。

所报告的场景如下：

隐藏在外部共享文档中的恶意指令可能会让 Copilot 修改在 Word 中起草或编辑的文档，并将攻击传播到新文档中。

完整攻击概述

攻击者在一份文档中放置隐藏指令，该文档随后被用作 Copilot for Word 的源材料。Copilot 可能会将这些指令理解为用户请求的一部分，从而操纵正在起草或编辑的文档。随后，Copilot 还可能将隐藏指令复制到生成的文档中，使该文档成为新的攻击载体。如果之后在另一个 Copilot 辅助工作流中使用这一载体，即使攻击者的原始文档已不在场，指令仍可再次触发并传播到更多文档中。

假设一名员工正在准备财务报告。这名员工从一个已遭入侵的可信网站下载了一份市场分析，却不知道该文档包含隐藏指令。随后，该员工在使用 Copilot 起草报告时，将这份分析作为源材料。隐藏指令会使 Copilot 修改财务报告中的内部数字，并将攻击复制到新文档中。员工保存这份表面上完全正常的报告，并在内部进行共享。之后，一名同事将其作为另一份报告的源材料；这些指令会再次触发，修改新报告，并将自身继续复制下去。因此，即使遭入侵的网站和最初的恶意文档不再参与，攻击仍可继续。随着受影响的报告被重复使用，更多报告和文档都可能成为攻击载体。

发布时的披露状态

协调披露：通过 MSRC 和 Microsoft 产品团队处理

本文包含：Microsoft Copilot for Word 中的 XPIA 和自我传播场景

客户操作：截至发布时，没有任何客户侧修复措施能够完全解决此问题。客户可以通过以下方式降低风险：在使用 Copilot 时，将来自外部的文档视为不受信任。在启动 Copilot 生成或编辑操作之前，审查所有附加文档。在重新使用、共享或分发由 Copilot 生成或编辑的文档之前，仔细审查这些文档。

在使用 Copilot 时，将来自外部的文档视为不受信任。

在启动 Copilot 生成或编辑操作之前，审查所有附加文档。

在重新使用、共享或分发由 Copilot 生成或编辑的文档之前，仔细审查这些文档。

Microsoft 侧状态：测试已证实，即使部署了当前所有缓解措施，该攻击仍然可以复现。截至发布时，针对这一更广泛漏洞类别，尚无可靠的缓解措施。

关于在修复前进行披露的说明

与第 1 部分和第 2 部分不同，该场景在本文发布时仍可被利用。我对此进行了慎重权衡。与 Microsoft 商定的协调期已经用尽，并且测试表明，目前尚无针对这一更广泛漏洞类别的可靠缓解措施。包括模型升级在内的两次缓解尝试，都未能解决整个漏洞类别。

因此，我选择在漏洞类别层面进行披露，而不是在具体载荷层面披露。我的理由是，如果防御者不知道某项风险的存在，就无法降低相关暴露；而且，这里介绍的传播机制会影响许多组织已经依赖的常规文档工作流。隐瞒该问题的存在，会让这些组织无法作出知情决策，同时也不会带来任何额外保护。

2026-03-06：向 MSRC 提交初始报告，其中包含复现步骤、视频、环境假设和 PoC 提示词。

2026-03-09：MSRC 确认收到报告并立案。

2026-03-31：Microsoft 确认所报告的行为。

2026-03-31：Microsoft 产品团队开始开展缓解工作；技术讨论持续进行。

2026-04-03：首个缓解措施上线（全新的“Edit with Copilot”体验）。

2026-04-09：确认原始攻击提示词的措辞已在“Edit with Copilot”中得到缓解。

2026-04-09：使用一项新的 XPIA 提示词任务（操纵财务数据），在“Edit with Copilot”中复现攻击行为。作为单独案件向 MSRC 报告。

2026-04-10：MSRC 确认收到报告并立案。

2026-04-10：Microsoft 产品团队开始开展缓解工作；技术讨论持续进行。

2026-06-08：应 Microsoft 要求，公开披露日期推迟至 2026-07-15。

2026-07-14：第二项缓解修复上线。该缓解措施包括将底层模型升级到 GPT-5.5。

2026-07-15：使用当时最新可用的模型 GPT-5.6，成功复现了带有蠕虫式传播的攻击利用。

2026-07-15：我建议将披露时间进一步推迟两周，至 2026-07-28，以便为新的缓解措施留出时间。

2026-07-15：Microsoft 同意。

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 仍然能够完整读取。还可以将攻击嵌入一份表面无害且包含与任务相关文本的文档中，进一步隐藏攻击。

该攻击要求恶意文档作为 Copilot 在 Word 中上下文的一部分。因此，根据所使用的 Copilot 版本，受害者必须执行以下操作之一：

在 Copilot for Word 中主动附加或上传文档

使用 work/Work IQ 模式中的"用 Copilot 编辑"功能，让 Copilot 在受害者的 OneDrive 中寻找恶意文档。在这种情况下，Copilot 必须认为该文档相关，并将其纳入上下文。因此，攻击者需要制作一份文档，以增加其中任一或两者都被纳入的可能性。

该漏洞对 Word 中的"magic pen"和"用 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： 该图表明在撰写本文时使用了 OpenAI 的最新模型 GPT-5.6 进行这些 PoC。

图 4： 在将 Q1 财务报告草稿中的所有财务数字减半后，Copilot 也使用白色文本附加完整的攻击提示，有效地将其隐藏在受害者的视线中。它也不会提及其减半数字或包含攻击的事实。因此，受害者对此一无所知。[大多数 XPIA 文本出于安全原因已模糊处理]

图 5： Copilot 不需要受害者附加恶意文档。在这个屏幕截图中，受害者仅指示 Copilot 撰写一份 Tfosorcim Q1 财务报告。Copilot 随后搜索受害者的 OneDrive 以查找相关文档。在这些文档中，我们找到了恶意的市场分析文档。该文档不与其余 Tfosorcim 文档位于同一文件夹中。但是，Copilot 仍然找到了它、读取了它，并被成功利用。

第二阶段是自我传播阶段。它完全依赖于指示 Copilot 将恶意提示复制到受影响文档中的说明。一旦受影响文档包含了提示，新文档本身就成为了新的攻击向量。

图 6： 屏幕截图显示了一个使用 Copilot 的新起草会话。这次原始攻击向量不再包含在附件中。但是，之前创建的文档已包含在其中（Tfosorcim Q1 2026 report.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 等系统更深入地集成，这些系统将该助手扩展到文档、工具和协作工作流的自动操纵和创建。在这样的系统中，本文所述问题的实际影响可能会快速扩展。基础机制保持不变，但其传播或影响的潜在范围以机器的速度扩展。

缓解漏洞

Microsoft 成功缓解了最初提交的 PoC 提示，并在本次披露的过程中部署了多项修复。这些修复中的每一个都通过关闭所报告的特定载荷来提高了防护标准，随后重现该行为需要更改的载荷，而不是直接重用旧的载荷。

然而，原始报告也描述了更广泛的漏洞类别：嵌入源文档中的指令可能影响 Copilot 的生成结果，并将自身复制到下游文档中。改变所请求的操作或措辞会改变载荷，但不会改变底层漏洞或传播机制。通过使用修改后的载荷，即使部署了所有缓解措施，完整攻击链仍可复现（本报告中的 PoC 就是一个实例）。因此，截至本文发布时，这类漏洞仍可被利用。

这类漏洞尚未被彻底解决，也反映出其底层问题的棘手程度。正如结语中所讨论的，这一弱点属于架构层面的问题，并且普遍存在于当前基于 LLM 的系统中。据我所知，目前任何同类产品都没有针对这类漏洞的完整缓解方案。要彻底解决它，需要开展研究，而不是打一个补丁就能完成。在这些限制下，Microsoft 的修复确实显著降低了风险敞口，而第 1 部分和第 2 部分中涉及的记忆与电子邮件正文攻击向量则已被完全缓解。我要感谢 Microsoft 为解决这一真正棘手的问题持续付出的实质性努力。

结合本系列前两部分来看，这些发现揭示了现代工作环境中一个更广泛的问题。也就是说，在将 LLM 集成到日常工作流程的系统中，信息完整性会成为首要安全问题。上述场景表明，攻击者控制的内容不仅能够影响单次输出，并可能造成信息泄露；攻击本身还可以在正常的用户工作流程中被复制并自我传播。

这带来的挑战远远超出了初始利用阶段。一旦恶意指令被嵌入生成的内容中，它们便可能持续存在于不同文档中，由合法用户重新分发，并被再次引入新的上下文。到了这个阶段，攻击将不再依赖最初的入口，而是已经成为系统内部信息流的一部分。

另一个相关影响是可追溯性的丧失。由于受影响的内容通过合法工作流程生成和修改，事后将很难确定操纵行为的来源。这使检测与响应都变得更加复杂，尤其是在此类内容被广泛共享的环境中。

除防范提示注入之外，生成的文档还应在元数据中保留源材料以及模型所执行编辑的来源信息。此类控制措施无法阻止底层注入，但可以显著提高可追溯性。

本系列中的发现所指向的问题超出了任何单一产品或实现。它们暴露了当前基于 LLM 的系统中一个更广泛的架构弱点。

为了让 AI 助手真正有用，它们通常必须处理电子邮件、文档、网页、记忆、工具输出以及其他可能受攻击者控制的信息。要处理这些信息，就必须将其纳入模型的上下文窗口，而它们会在其中与系统指令、用户请求及其他可信信息参与同一次计算。

这造成了一个根本性问题：LLM 必须处理外部内容，才能判断其含义、相关性，以及其中是否包含攻击。但当它作出这一判断时，攻击者控制的 token 已经在影响生成该判断的计算过程。被检查的内容本身参与了检查行为。因此，依赖模型检测 XPIA，就如同要求一个解释器执行不受信任的程序，以判断该程序是否可以安全执行。

在恶意内容到达目标模型之前检测并移除它，只不过是将同一个问题向外转移了一层。

由于 LLM 能够从截然不同的表示形式中恢复语义，有效的检测器必须具备与之相当的语义恢复能力。能力弱于目标 LLM 的检测器只能覆盖较小的表示空间，从而遗漏那些目标模型能够理解、但检测器无法识别的恶意表达方式。

目前唯一普遍可用且具备同等语义能力的技术，是另一个 LLM。将一个模型放在另一个模型之前，或许可以降低某些特定攻击的成功率，但这会造成“LLM 层层嵌套、无穷无尽”的问题：每引入一个用于保护另一个 LLM 的 LLM，它自身也必须受到保护。

长期挑战很可能在于设计这样的系统：目标与意图可以独立于正在处理的信息而存在。当前的 LLM 架构无法在意图与解释之间提供可靠的隔离。因此，在当前嵌入 LLM 的系统中，攻击者控制的信息不仅能够影响模型生成什么，还能影响模型认为自己被要求生成什么。

因此，现今任何将 LLM 集成到可信工作流程中的系统，都必须假定：攻击者控制的内容一旦进入模型上下文，就会以一定概率导致系统失陷。

以下变更日志展示了本文哪些部分在什么时间发生了变更。拼写错误及类似问题不会记录在案，但我会尽力列出文章中任何具有实际意义的修改。

2026-07-28：添加变更日志

2026-07-30：修正了时间线中关于攻击类别可复现的一行内容。