Copilot严重漏洞曝光：攻击者可绕过2FA窃取用户验证码
漏洞速览：2FA 安全防线形同虚设？
上周二，微软修复了其 M365 Copilot AI 平台上一个严重等级为“最高” 的漏洞。本周一，发现并报告该漏洞的研究人员公开了其概念验证（PoC）利用方式：攻击者能够从 Copilot 可访问的邮件中窃取双重身份验证（2FA）代码及其他敏感数据。
根源：AI 的“轻信”无解？
这并非孤立事件。微软及其他大语言模型（LLM）提供商一直无法阻止其产品遵从恶意请求泄露数据。根本原因在于：AI 机器人无法区分用户提供的指令与隐藏在第三方内容中的恶意指令。当模型为用户总结、起草回复或执行其他操作时，这些恶意指令可能被悄然注入。由于无法守住这一关键边界，微软等公司只能不断设置复杂且临时的护栏，试图遏制这种“先天轻信”带来的后果。
绕过护栏：参数到提示注入（Parameter-to-Prompt Injection）
Varonis 安全团队设计了一条攻击链，成功跨越了微软设置的防护措施。其核心是所谓的 “参数到提示注入”（Parameter-to-Prompt Injection）。与传统的提示注入不同，恶意命令并非藏在邮件或文档中，而是被置于 URL 的查询参数（如 ?q=）中。当 Copilot 处理此类 URL 时，会将参数中的恶意指令解释为用户意图的一部分，从而泄露数据。
已有护栏为何失效？
微软此前已部署多项防护：例如将 Copilot 输出包裹在 <code> 块中，防止浏览器将其解析为可执行内容；同时限制 Copilot 只能访问受信任的 Microsoft 域名。然而，攻击者利用标记语言（如 <img> 标签）诱导 Copilot 向攻击者服务器发送包含敏感数据的请求，从而绕过限制。当 Copilot 尝试加载图片或提交表单时，数据即被外传。
行业反思：LLM 安全何去何从？
此次漏洞再次证明，当前 LLM 安全策略存在结构性缺陷。依赖临时补丁和规则集难以应对不断演变的注入手法。业界亟需从模型架构层面解决指令来源的隔离问题，例如引入更严格的上下文隔离机制。在此之前，用户应谨慎对待 Copilot 等 AI 助手处理敏感信息的能力，尤其是涉及 2FA 代码等高价值数据时。