Copilot安全漏洞：AI自己泄露了攻击路径

2025 年 12 月 31 日，Varonis 的安全研究人员向微软提交了一份关于 Microsoft Copilot 漏洞的报告：该漏洞允许通过一次点击，静默地从用户已连接的 Gmail、Google Drive 以及 Copilot 自身的对话记忆中窃取数据。微软在五周后的 2026 年 2 月 1 日发布了部分修复补丁。而完整的补丁直到 2026 年 8 月 18 日才上线——距离首次报告已过去了将近八个月，距离本文撰写也仅剩几天。

这个时间差值得玩味，但这并非故事最有趣的部分。最有趣的部分在于 Varonis 是如何首先发现这个漏洞的。他们没有对 API 进行模糊测试，也没有对 JavaScript 包做 diff，而是直接打开了 Copilot 的聊天窗口，反复询问它：为什么他们所描述的攻击在理论上是不可能的——而 Copilot 的拒绝回答不断泄露了构建该攻击所需的关键架构细节。

Varonis 将这项技术称为"元黑客"（meta-hacking），由此产生的漏洞链被追踪为 CVE-2026-24301，别名 CoSnitch。

发生了什么

CoSnitch 影响的是 Copilot Personal——即面向消费者的版本，具备记忆功能和已连接应用的访问权限——而非面向企业客户的 Copilot，后者在整个事件中均未受影响。该漏洞允许攻击者构造一个 URL，用户点击后，Copilot 会自动执行攻击者提供的 prompt，无需受害者的任何进一步交互。由于受害者已处于认证状态，该 prompt 在其活跃会话中运行，可以访问他们已连接的任何账户：Gmail、Google Drive 以及 Copilot 自身对先前对话的持久记忆。

Varonis 表示，没有证据表明该漏洞在修复上线前被利用。这是好消息。结构性坏消息是：一款具备广泛账户访问权限的消费级 AI 助手，竟然仅通过一个链接就能被触及——这是互联网上最古老的攻击原语，指向了最新的攻击面。

元黑客技术实际如何运作

根据 Varonis 研究员 Lior Adar 的描述，其机制一旦看透，简单得近乎可笑：

"一开始 Copilot 一直在拒绝，但每一次拒绝都泄露了关于其内部架构的技术细节。Copilot 最终披露了一些未文档化的参数。我拿到这些参数后，用它们来构造自动运行的 prompt。"

以下是那场对话的形态。Adar 的团队怀疑 Copilot 的聊天界面接受 URL 参数，这些参数可以预填充或触发一个 prompt——这是"分享此对话"或"深链到特定查询"功能的常见模式。他们没有对每种参数组合进行黑盒测试，而是直接询问 Copilot：URL 是否可以在用户不按回车的情况下自动运行 prompt？Copilot 作为一个助手，在被问及关于自身的技术问题时，表现得完全恰到好处——它解释了为什么这个特定顾虑不适用——而在此过程中，它描述了它正在防御的参数设计。每一条"不，因为 X"的回答本身就是一份规范泄露。把拒绝重新定义为后续问题，提取更多画面细节，重复这个过程。

这个过程最终揭示了两个截然不同的 URL 参数，必须同时使用：

?q=——用攻击者提供的文本预填充 Copilot 的输入框，但仍需要受害者按回车键。

?autorun=1——这个未文档化的参数跳过了那一步，在页面加载时自动执行预填充的 prompt，无需任何进一步交互。

单独看任何一个参数都不构成危险。没有 ?autorun=1 的 ?q= 只是一个便捷功能——甚至可以说是一个合理的深链到特定查询的功能。正是这两个参数的组合，加上微软显然从未打算让外部人员发现的一个未文档化标志，把一个 UX 快捷方式变成了一次点击账户接管的原语。点击了陷阱链接的受害者，相当于给攻击者提供了一个正在其 Gmail 和 Drive 上运行的、已认证的、具备工具调用能力的 AI 智能体。

为什么"询问模型"才是真正的新闻所在

Prompt 注入本身并非新鲜事物——它是过去两年讨论最多的 AI 安全类别，每个发布带工具调用访问权限智能体的供应商都发布过某种形式的缓解措施。CoSnitch 值得更深入审视的原因不在于漏洞类别，而在于侦察方法。

传统的 API 模糊测试假设目标是沉默的——你发送输入，从输出、错误码、时序推断行为。元黑客则假设目标会主动用自然语言回应，其目标是尽可能提供帮助和透明地解释其工作原理。从安全研究的角度来看，"那不可能发生，因为参数 X 会阻止它"这样的拒绝，与规范泄露无法区分。模型没有故障。它正在做一款经过"有帮助且无害"调优的助手应该做的事：准确地回答关于自身的问题。这种本能正是被武器化的东西。

这对于任何在具备系统访问权限、工具调用或连接数据的模型之上构建产品的人来说都很重要——不仅仅是微软。如果你的智能体在被问到"为什么你不能做 X"时会解释自己的护栏，那你已经构建了一个自我文档化的攻击面。解决方案不是"让模型撒谎其架构"——那本身就有明显的问题——而是认识到，助手对其自身限制的解释现在是你威胁模型的一部分，就像二十年来详细的错误信息或堆栈跟踪对传统应用安全一样。

与前智能体时代对比

对比一下 2015 年假设存在的同一底层缺陷：一个带有未文档化 autorun 查询参数的 Web 应用，跳过确认步骤。这是一个真正的漏洞，但其爆炸半径受限于那个应用本身能做的事情。CoSnitch 的爆炸半径受限于 Copilot Personal 已连接集成的范围——按照设计，这跨越了多个通过 OAuth 连接的第三方服务。漏洞存在于微软的产品中，但可利用的表面是用户已连接到它的所有内容的并集。

这就是智能体 AI 产品引入的结构性转变：攻击面不再仅仅是"这个应用的代码"，而是"这个应用的代码，加上它被授予对每个它被允许触碰的服务的每个范围的权限，减去模型在推理时应用的任何护栏"。存在于概率模型中、通过模型本身的自然语言社会工程可触及的护栏，是一道根本性更柔软的边界，而非硬编码的权限检查。CoSnitch 是对这一差距的清晰证明，而非一个一次性的实现错误。

这也是一个教科书级别的"混乱代理"（confused deputy）问题实例——这种问题在 AI 出现前几十年就已存在：一个被信任的中间人（Copilot，以用户身份认证）被诱骗代表攻击者使用其自身的合法权限。新的是交付机制。经典的混乱代理攻击需要对 API 构造请求。而这一次只需要一个构造的 <a href>——这正是自 1990 年代以来驱动电子邮件网络钓鱼的同一原语，现在指向了一个目标：该目标拥有对用户收件箱、文件以及 AI 保留对话历史的读写权限，而不仅仅是一个会话 Cookie。Web 上最古老的社会工程向量被证明可以与其最新、最具特权的客户端完美组合。

对构建智能体的团队的实际建议

如果你正在此类别中构建或保护产品，有几点可以直接付诸行动：

审计你的助手 Web 界面接受的每个 URL 参数，特别是任何可以预填充或触发 prompt 的参数。如果某个参数可以在没有用户积极操作（点击、回车键）的情况下推动对话，就将其视为自动执行原语并相应地进行威胁建模——深链应该需要确认，而不是静默跳过。

不要让"询问模型"成为你唯一的纵深防御层。如果你的智能体被要求解释为什么某条攻击路径被关闭，它的回答可能正在泄露该关闭的机制。考虑架构敏感性问题是否应该得到通用非技术性回答而非详细回答，就像你不会让 Web 服务器向未认证调用者解释其自身的 WAF 规则一样。

严格限定已连接账户的访问范围，并对深链入口点进行日志记录。CoSnitch 的实际损害来自通过 OAuth 连接的 Gmail、Drive 和记忆——而非 Copilot 的核心聊天功能。最小权限范围界定，以及对通过 URL 入口触发（而非会话中打字触发）的操作分别进行审计日志记录，即使 auto-run 漏洞存在，也能限制爆炸半径。

对于智能体产品来说，打补丁时间比以往更重要。传统 Web 漏洞在被利用前一直存在。AI 助手漏洞则在助手本身被日常使用、用户已授予其对收件箱的持续访问权限的情况下持续暴露——暴露窗口以不同方式复合。

披露留下的未解之谜

Varonis 的叙述和微软的回应都有真正的空白。没有公开说明为什么修复从 2 月 1 日（部分补丁，解决 auto-execution）到 8 月 18 日（完整修复）花费了超过六个月——根据所描述的两个参数组合，读起来像是在第一个补丁上线时就已经是一个可控制和充分理解的漏洞。微软表示无需客户采取行动，企业客户不在范围内，但没有发布详细的根本原因事后分析来解释延迟——这是安全团队评估供应商信任时真正想要的部分。

同样不清楚的是，?autorun=1 是否是同类中唯一的未文档化参数，或者同样的元黑客方法——耐心询问 Copilot 的拒绝回答——是否会发现其他参数。Varonis 的报告展示了一种方法，而非详尽的审计。鉴于该方法只需要一个聊天窗口和耐心，有理由认为其他研究人员（以及不太道德的行为者）已经在对 Copilot 及其竞品运行相同的玩法。

竞争和行业背景

Copilot 并非唯一提供具备已连接第三方账户和基于 URL 入口点的 AI 助手的——ChatGPT 的连接器和 Gemini 的扩展同样属于同一产品类别：一款智能体，通过 OAuth 获得对用户邮件、文件和日历的持续访问权限，按设计可以通过分享链接和深链触及——因为这正是用户要求的便利功能。这一切并不意味着 CoSnitch 是微软特有的失败，不如说这是整个智能体助手类别共同面临的风险的一个早期、具体实例。这里的区分事实是披露方法，而非漏洞的独特性——这个领域的每个供应商，只要发布了"可分享的 prompt 链接"或"深链到对话"功能，都有同一类风险需要排除，而且很少有谁发布过关于当助手本身被用作针对其自身实现的侦察工具时会发生什么的安全审查。

大多数 CoSnitch 报道的框架——"AI 助手被骗泄露自己的架构"——低估了实际发生的事。Copilot 并非被欺骗输入越狱载荷的那种"被骗"。它被问了普通的、听起来善意十足的技术问题，它 kompetent 且诚实地回答了。这可以说是一个更令人不安的发现：故障模式根本不需要对抗性 prompt 技术，只需要耐心和愿意把"为什么不"作为一个研究问题而非死胡同来对待。任何目前通过向智能体抛出越狱 prompt 库来进行红队测试的团队，都应该把"礼貌地请它解释自己的护栏"加入检查清单，因为这是这里真正有效的技术。

八个月的时间线是故事另一半值得审视的部分。微软的信息——无野外利用证据、企业不受影响、无需客户行动——都是站得住脚且可能准确的，但无论修复实际花了多长时间，这同时也是标准的供应商说辞。结合"一次点击"、"无需用户交互"、"可访问邮件加文件加 AI 记忆"的漏洞，部分未修复超过半年，确实是这类严重漏洞的漫长窗口，而没有发布对该时间差距的详细根本原因解释，是这次披露中值得比目前得到更多审查的部分。

谁应该采取行动

Copilot Personal 用户无需做任何事情——修复已部署，微软表示无需客户行动。如果你注重安全，审查一下你的 Copilot 实例具有哪些 OAuth 访问权限并删除任何你不积极使用的仍然是值得的。

正在构建具备已连接账户访问权限或深链/URL 触发 prompt 的 AI 智能体的团队，应该将此视为直接行动项目，而非背景阅读：审计你自己的 URL 参数表面，查找任何类似 autorun 风格的行为，并考虑你的智能体对自身护栏的解释在持续、耐心的询问下是否可能充当规范泄露。

在智能体 AI 产品上工作的安全研究人员和红队队员有一种新技术值得加入标准工具包——元黑客成本低廉，除了聊天窗口和耐心外不需要任何特殊工具，而且这次披露是它能找到常规测试数月都未发现的真实、高危漏洞的工作证明。它也可以与现有的 prompt 注入测试套件自然组合：不要只向模型抛出对抗性载荷，花一个会话询问它关于自身限制的简单问题，记录每个回答，寻找任何读起来像规范而非策略的内容。

发布"连接你的账户"AI 功能的产品和平台团队——现在包括大多数主要助手——有一个更窄但更尖锐的教训：任何深链或分享链接功能按构造来说都是一个经过认证会话的基于 URL 的入口点，它应该获得与 OAuth 回调端点相同的审查，而非通常"便利 UX 功能"获得的较轻内部审查。

其他人都可以安全地将此视为参考性而非紧急性的信息——但当你下次有产品把"把收件箱连接到我们的 AI 助手"作为无摩擦便利功能推销时，这是一个有用的数据点。

你怎么看：耐心询问模型自身的拒绝是否算作团队应该主动进行红队测试的安全研究技术，还是更接近于 Copilot 护栏实现方式的偶然怪癖？