Microsoft 365 Copilot：一个开放重定向模糊了租户边界

这是什么？

2026年7月2日，微软发布了一则关于Microsoft 365 Copilot中权限提升漏洞的安全公告，评级为严重。该漏洞是一个开放重定向——一个可诱导Copilot将其视为可信、实则指向不受控目标的URL——但其后果对这一漏洞类别而言并不寻常：它可让已认证的攻击者跨越本应将一个Microsoft 365租户的数据与另一个租户隔离开来的信任边界。在微软描述的最坏情形中，某组织内的一个低权限账户能够触及属于另一组织、使用同一Copilot服务的文件、邮件或Teams消息。微软已在服务端修复该问题，客户无需安装任何补丁。尽管如此，这一事件清楚地说明：一旦LLM助手位于授权链的中间，一个平平无奇的Web弱点也会变得严重。

工作原理

Copilot并不是回答单个问题的单一模型，而是一个编排层：它将用户的提示分发到Microsoft Graph、SharePoint Online、Exchange和Entra ID，检索用户被授权查看的内容，再组合出答案。其中每一次检索都应在查询时以发起请求的用户身份进行授权。

该漏洞就潜藏在这条编排接缝中。开放重定向意味着助手所处理的链接可以将其引向受攻击者影响的目标，而周围的请求仍保持着可信的第一方流程的外观。根据公开公告及其后的分析，这一度模糊了”本租户数据”与”彼租户数据”之间的区分：在某些条件下，编排引擎将来自不同租户的内容当作同一权威域的内容来对待。由于Copilot将其检索记录为应用程序的操作而非用户的操作，请求的真实来源也可能被掩盖——这恰恰使此类漏洞在事后难以被发现。

目前没有公开的利用代码，我们也不会复现。机制比任何载荷都更重要：当一个LLM助手被授予广泛的、跨服务的读取权限，随后又信任了一个本应重新校验的重定向时，模型的触及范围就变成了攻击者的触及范围。

为何重要

开放重定向通常被归为”低危”。此处抬高风险的，是重定向背后组件的影响半径。一个能够对整个租户的邮件、文档和对话进行推理的副驾驶，按设计就对敏感数据拥有极广的视野。请求授权中的一次失误泄露的不是一个文件，而可能暴露语料库中任意的一部分，在本例中甚至可能是相邻组织的语料库。租户间隔离是多租户SaaS的核心承诺之一；一条哪怕短暂跨越该边界的权限提升路径，对任何受监管的环境都是首要关切。

更宏观的教训是架构性的。随着助手成为访问企业数据的默认接口，它们继承并放大了底层的每一处配置错误和每一个信任假设。一个权限过宽的SharePoint站点，本是潜在风险，一旦副驾驶因某次提示而将其内容浮现出来，就变得可触及。安全团队现在应将AI助手视为高价值、高权限的应用，并据此进行威胁建模——包括专门测试精心构造的提示或被处理的链接能否跨越租户边界的红队演练。

防御措施

服务端修复消除了这条具体路径，但它所揭示的暴露面是结构性的，无论如何都值得加固。

• 约束助手的身份。 审查在Entra ID中授予Copilot服务主体的权限，剥离其不需要的任何租户级Graph范围。助手的读取范围越窄，未来任何授权失误的影响半径就越小。
• 加固底层数据。 审计SharePoint Online的外部共享和站点权限。对含敏感数据的站点，限制或禁用外部共享：副驾驶无法泄露它从未被允许索引的内容。
• 审查跨租户访问设置。 在Entra ID外部身份中，检查入站和出站的跨租户配置，将信任降至B2B协作真正所需的最低限度。
• 将Copilot活动作为一级日志源来监控。 在Microsoft 365 Defender门户中，排查返回意外来源数据的提示，或缺乏明确业务理由的访问。由于操作以应用程序名义记录，应聚焦于异常的检索模式，而不仅是用户归因。
• 校验每一次重定向，并在检索时重新授权。 对于自建LLM助手的团队：绝不要让模型凭信任跟随重定向。重新校验最终目标，并在每次数据获取时以用户身份重新检查授权，而不只是在入口处。
• 对助手而非仅对模型进行威胁建模。 将”一个提示或链接能否跨越租户或权限边界？“纳入测试计划，并把编排层——而非LLM权重——视为主要攻击面。

状态

该漏洞由微软于2026年7月初披露并修复。客户无需任何操作即可获得修复，但上述配置加固仍然有效。

项目	详情
受影响产品	Microsoft 365 Copilot（跨SharePoint Online、Exchange、Entra ID、Microsoft Graph的编排）
类别	开放重定向 → 跨租户权限提升
厂商严重性	严重
前置条件	已认证且对租户已有一定访问权限的攻击者
修复	由微软在服务端应用；无客户端补丁
参考	CVE-2026-41106（MSRC安全更新指南）
披露	约2026年7月2日