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